Porting *nix Applications to NT (win32) enviroments

Porting *nix Applications to NT (win32) enviroments

Post by Jo » Sun, 19 Apr 1998 04:00:00



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


 
 
 

Porting *nix Applications to NT (win32) enviroments

Post by Uwe Bonne » Sun, 19 Apr 1998 04:00:00


: 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.

Hallo,

it will depend on the code. It should be straightforward for command
line applications. As lcc-win32 has a small footprint, a try should be
easy.

Bye

--

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

 
 
 

Porting *nix Applications to NT (win32) enviroments

Post by Karl Garriso » Sun, 19 Apr 1998 04:00:00



> 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



Check out:

http://www.cygnus.com/misc/gnu-win32/

...for a free enviroment for porting UNIX apps.

--
Karl Garrison

 
 
 

Porting *nix Applications to NT (win32) enviroments

Post by Rick Kwa » Wed, 22 Apr 1998 04:00:00



> 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