Are you saying, "I won't believe it until someone has tried it", or are you saying, "I know of it having been tried and failed"?
The two are not exactly equivalent. Yes you can tweak a registry key - with a bit of effort in 2000 - but this does not completely solve the problems: Many server software apps will fail. You may need additional exe's and in 2000 there are some changes relative to NT4 that make throwing the registry switch an insufficient operation to acheive parity with server. In short, yes, I have tried it and the posted solution does not work in general in windows 2000 or greater. It can be done however but the work involved is significatly greater in 2000. Unless your time is worth nothing IMHO it really is not worth the trouble. FYI you can get Linux if you really need a cheap or free server operating system.
"Not work" is good enough for me. Already have Linuxes (Linuxae? Linuxi? Linuci?). Was intrigued by the Win server hack, only because I can't completely dispense with Win, and hoped that "server mode" might bring better reliability through stricter enforcement in internals constraints.
Most reliability problems in Win2000 are due to issues with the software writers not Windows. IMHO it is significantly more difficult to write robust, high quality software for windows paltforms than for Unix variants. Bottom line: if you have hardware that is on the windows 2000 / xp compatibility list and use software certified for windows you should have few problems. The other trick is the configuration which is admittedly still a bit arcane. FYI Our Windows 2000 servers have been running for nearly 3 years with 99.99 % or greater up time, and running heavy loads. Of course, so have our UNIX servers ...
Gotta disagree. The main problem as I see it is that most programmers with many years of experience learned on a Unix type platform. Programming for Windows environments is quite a bit different. I learned to program in Windows environments and working on projects with these old school Unix guys drives me nuts. They don't do things the way MS recommends, they do things the way they have always done them, and that is where the problems arise. They are so stubborn in their ways, they won't adapt to using a different style. It worked on a Unix environment, so by God it should work on an MS environment, and if it doesn't then Bill Gates is obviously the devil. Hopefully that doesn't start a flame war. Just my opinion.
No flame war.... Design and implementation of software for Unix is different than for Windows: While an abstract design may be universal - a pattern say - the physical implementation is in some cases quite different between a Unix target and a Windows target. Two different skill sets are required. The fact is that Windows development is more complicated precisely due to the patched nature of the windows OS - at all three major layers. There is little uniformity between the API's or infrastructure support - error reporting, return codes etc - and since the API is soo large there are numerous errors in the documentation that can only be learned through trial and error. Many of the tricks for writing high quality server software for Windows server OS's are not generally known. Also there is quite a bit of "churn" by MS in revising and adding to their API's. We spend more time validating and testing our systems written for MS systems that we do for UNIX systems. We dont view the skill sets - UNIX software implementation versus MS software implementation - as interchangable.