> I was wondering if anyone has any experiance with porting Linux or Unix Code to
> NT or 95? I've tried several GNU's.But with out success.
> I really don't have alot of $$$ to buy comerical packages, but could
> depending on the price. I've seen some that claim to be able to.
> Jon Marsalek
Simple command line apps work as MS console apps. That seems
okay. After that, it is probably time to learn WIN32 in depth.
I did not use one of the commercial packages to put a wrapper
around our UNIX apps to interface to NT. I am told they are
okay, but you will nevertheless have to rewrite to fit NT;
there is too much performance lost. (They are also expensive;
cheap for initial time-to-market, but you will want to revisit
the work anyway.)
I used MS Visual C++ / Developer Studio 4.2 to rebuild apps
from UNIX environment. I am tempted to put together a full
list of what we ran into, but this is what I currently recall.
* UNIX daemons are replaced by services, which will need
some additional wrapper code to fit the service model.
* select() only works on sockets, not files or the keyboard;
if you had a global select() that handled all of these,
be prepared to write additional code with ReadFile(),
Microsoft-style events, CreateThread(), etc.
* fork()/exec() is replaced by spawn(), but I ended up rewriting
code to use MS CreateProcess().
* There are other POSIX style interfaces which exist, but I ended
up using a lot of MS replacements.
pipe() ==> CreatePipe()
dup() ==> DuplicateHandle()
close() ==> CloseHandle()
* GetStdHandle() was real interesting... I recall that there
were lots of subtle restrictions.
* watch out for that first call to tempnam(). I got filenames like
"s51.", "s51.1", "s51.2". When you create file "s51." you really
get "s51", causing strcmp() to fail the match.
* I was able to free() and string created with strdup() using
debug library. It crashed using retail library. Going thru
the assembly code with someone, we discovered that retail
botched or ignored the malloc chain. I ended up writing
my own strdup(), which was easy enough. The aggravation
was having things work correctly in the debug environment,
recompile for retail where debugging tools are virtually
useless and then discover the retail library was at fault.
* The MS notion of mutex (as opposed to critical section) is
interesting.
If you have to, you have to. But from my experience "have to"
had better have a really good justification. Based on what I
saw, I'd guess at a 2:1 to 3:1 productivity improvement. Hence,
that's where I'd put the threshhold for the justification.
The other way out is to buy into MS's developer kits, which
strike me as a bunch of quick, point solutions. You are spared
getting into the depths of what your app really does (because
MS has already figured that part out for their environment).
Some of these are directly downloadable from the MS website.
But then, we're no longer talking about porting. We're now
building on top of the MS infrastructure.
--Rick Kwan