Ok, so I worked for a company that was actually using Mainwin for a while. We had a suite of EDA tools for Windows that needed to be ported to Unix. I was the engineer who was in charge of doing the port of the first product. As such, I am quite familiar with the ins and outs of Mainwin, at least as of 9 months ago, and as it applies to the Solaris platform.
The deal with Mainwin is that they've essentially taken the NT source and re-written the "bottom" half -- i.e. the hardware access and low-level interfaces. Then, they compiled the entire NT kernel on top of this layer of cruft.
In order to compile anything on top of the Mainwin libraries, you are dynamically linking to a fairly substantial portion of the NT kernel. Hence, the NT code license.
With this constraint, Mainwin has two major problems:
NT bugs + Mainsoft cruft layer bugs (and in our case, Solaris compiler bugs) add up to very buggy and slow applications. There's no reason that a reasonably snappy Windows app should be slow on a 4-processor Solaris server with 3 GB of RAM, but Mainwin managed somehow.
NT per-seat license + Mainsoft one-time license was sort of expensive. It was only the fact that our software was fairly expensive that made Mainwin feasible at all.
So, in short:
NT source license because that's their modus operandi
Office on top of Mainwin would be hideously unstable and unusable; hence, it's not likely
Windows media player and IE on Linux could happen, but they will be slower and considerably less stable than on Windows.
As far as programmers' thought processes when programming goes... Yes, maybe most commonly used languages are Turing complete. The fact of the matter is, though, that a programmer who is writing assembly language has to think differently about the problem than one who is writing in Forth, or one who is writing in Lisp, or C or C++. Different languages cater to different ways of approaching and thinking about the problem. It seems a bit...glib to say that since all (most) languages are capable of expressing an arbitrary algorithm that they are all based on the same fundamental structures of reasoning. Was it Knuth who said that a programming language which doesn't change the way you think about programming isn't worth learning?
That said, I've been told that Russian, for instance, has interesting facilities in the language for dealing with when a "verb" is taking place. (i.e. expressing ideas about concurrency which would require a bit more work in English) The person I've talked to who spoke Russian claimed that it was difficult to grasp these alternative verb forms, in spite of the fact that he spoke English and French with a fair degree of fluency. Native Russian speakers, obviously, are quite facile with the alternative verb forms. It may be, for instance, that a Russian programming language designer would feel the need to build facilities for concurrent actions into the programming language itself. This would be somewhat different from the most commonly used programming languages, where ideas about concurrency are shunted into the layers of standard (or non-standard) libraries.
Err... Being an English word doesn't seem to be an impediment to trademarking, though. Consider Tide, Brawny, Coke, and Hostess. Not that this isn't a completely ridiculous state of affairs, but... (i.e. try calling your product by one of these "well-recognized" names, and see if the "but it's an English word" defense holds up.)
MainWin, at least as of a year ago, was complete and utter crap. I worked for a company which was paying an absurd price to use MainWin, and the stability was pitiful. It's unstable because it's essentially Windows NT compiled on top of Unix, and it's expensive because Microsoft extracts a per-seat license from MainSoft who then passes the goodness on to you. If you are willing to pay Microsoft a per-seat licensing fee for every copy of your software that is sold...
Even memory verification aside, accessing something which is located in memory is slower than accesing a register. For instance:
mov eax, ebx
Is always faster than the single instruction:
mov eax, [ebx]
This is simply because registers are located in the processor and can be accessed in a single clock cycle, whereas even very fast cache RAM still takes a bit more than this, not to mention cache misses, et cetera.
Mainwin, at least, as of 6 months ago, was completely useless. Yes, it did successfully emulate the Win32 APIs. Unfortunately, it had about 10 times as many bugs as running natively on these APIs; Many of these bugs could either not be worked around, or were very difficult to work around. The company I was working for was porting their software from Windows to Unix using Mainwin, and eventually got tired of waiting for Yet Another Mainwin Patch to fix these critical bugs that prevented us from shipping. Perhaps Mainwin on Linux is better than Mainwin on Solaris, but... For the price we were paying them, we expected much more than we got. (Part of the price problem, however, is that their code includes parts of the NT source, and as such, they are required to license according to Microsoft terms -- i.e. you have to pay a per-seat runtime license for your software. For every copy of your software that sells, part of that goes to Mainsoft, and in turn, part of that goes to Microsoft.)
As far as the issue of types goes...
CHAR == char
WCHAR == wchar_t
TCHAR == ( unicode ? wchar_t : char )
The only real issue with MS types on non-MS compilers are the random MS extensions, which include 'uuid' attributes (for COM integration, basically), and unnamed structs, which many compilers don't support -- i.e. like:
union { int i; struct { char a; char b; }; };
In the above example, i and a are both located at offset 0 from the start of the struct, and b is located at offset sizeof(char) from the start of the struct. Normally, you would have to use:
union { int i; struct { char a; char b; } foo; };
and access a and b as foo.a and foo.b.
Not that it's a simple matter to handle the weird MS types, but it's a surmountable issue if you are willing to get into typedefs and some preprocessor ugliness.
Slashdot Mirror
Ok, so I worked for a company that was actually using Mainwin for a while. We had a suite of EDA tools for Windows that needed to be ported to Unix. I was the engineer who was in charge of doing the port of the first product. As such, I am quite familiar with the ins and outs of Mainwin, at least as of 9 months ago, and as it applies to the Solaris platform.
The deal with Mainwin is that they've essentially taken the NT source and re-written the "bottom" half -- i.e. the hardware access and low-level interfaces. Then, they compiled the entire NT kernel on top of this layer of cruft.
In order to compile anything on top of the Mainwin libraries, you are dynamically linking to a fairly substantial portion of the NT kernel. Hence, the NT code license.
With this constraint, Mainwin has two major problems:
So, in short:
In short, no big surprises.
As far as programmers' thought processes when programming goes... Yes, maybe most commonly used languages are Turing complete. The fact of the matter is, though, that a programmer who is writing assembly language has to think differently about the problem than one who is writing in Forth, or one who is writing in Lisp, or C or C++. Different languages cater to different ways of approaching and thinking about the problem. It seems a bit...glib to say that since all (most) languages are capable of expressing an arbitrary algorithm that they are all based on the same fundamental structures of reasoning. Was it Knuth who said that a programming language which doesn't change the way you think about programming isn't worth learning?
That said, I've been told that Russian, for instance, has interesting facilities in the language for dealing with when a "verb" is taking place. (i.e. expressing ideas about concurrency which would require a bit more work in English) The person I've talked to who spoke Russian claimed that it was difficult to grasp these alternative verb forms, in spite of the fact that he spoke English and French with a fair degree of fluency. Native Russian speakers, obviously, are quite facile with the alternative verb forms. It may be, for instance, that a Russian programming language designer would feel the need to build facilities for concurrent actions into the programming language itself. This would be somewhat different from the most commonly used programming languages, where ideas about concurrency are shunted into the layers of standard (or non-standard) libraries.
Err... Being an English word doesn't seem to be an impediment to trademarking, though. Consider Tide, Brawny, Coke, and Hostess. Not that this isn't a completely ridiculous state of affairs, but... (i.e. try calling your product by one of these "well-recognized" names, and see if the "but it's an English word" defense holds up.)
MainWin, at least as of a year ago, was complete and utter crap. I worked for a company which was paying an absurd price to use MainWin, and the stability was pitiful. It's unstable because it's essentially Windows NT compiled on top of Unix, and it's expensive because Microsoft extracts a per-seat license from MainSoft who then passes the goodness on to you. If you are willing to pay Microsoft a per-seat licensing fee for every copy of your software that is sold...
Even memory verification aside, accessing something which is located in memory is slower than accesing a register. For instance:
mov eax, ebx
Is always faster than the single instruction:
mov eax, [ebx]
This is simply because registers are located in the processor and can be accessed in a single clock cycle, whereas even very fast cache RAM still takes a bit more than this, not to mention cache misses, et cetera.
Nope. They go on the stack. (If they didn't, e.g. varargs functions like printf, sprintf, scanf, et al would not work.)
Mainwin, at least, as of 6 months ago, was completely useless. Yes, it did successfully emulate the Win32 APIs. Unfortunately, it had about 10 times as many bugs as running natively on these APIs; Many of these bugs could either not be worked around, or were very difficult to work around. The company I was working for was porting their software from Windows to Unix using Mainwin, and eventually got tired of waiting for Yet Another Mainwin Patch to fix these critical bugs that prevented us from shipping. Perhaps Mainwin on Linux is better than Mainwin on Solaris, but... For the price we were paying them, we expected much more than we got. (Part of the price problem, however, is that their code includes parts of the NT source, and as such, they are required to license according to Microsoft terms -- i.e. you have to pay a per-seat runtime license for your software. For every copy of your software that sells, part of that goes to Mainsoft, and in turn, part of that goes to Microsoft.)
As far as the issue of types goes...
The only real issue with MS types on non-MS compilers are the random MS extensions, which include 'uuid' attributes (for COM integration, basically), and unnamed structs, which many compilers don't support -- i.e. like:
In the above example, i and a are both located at offset 0 from the start of the struct, and b is located at offset sizeof(char) from the start of the struct. Normally, you would have to use:
and access a and b as foo.a and foo.b.
Not that it's a simple matter to handle the weird MS types, but it's a surmountable issue if you are willing to get into typedefs and some preprocessor ugliness.