From: Frare, S. A \(Steven\) <st...@av...> - 2004-11-07 14:37:15
|
Hi Andrew: I realize fork is a Unix-ism, however my understanding was that MinGW = supported Unix calls to aid in porting Unix apps to Windows, in which = case the fork() function call is often used. Unfortunately CreateProcess and it's friends do not provide similar = behavior to that of fork and aren't a good replacement. =20 Thank You Steve -----Original Message----- From: min...@li... [mailto:min...@li...]On Behalf Of Andrew Hart Sent: Saturday, November 06, 2004 9:51 PM To: min...@li... Subject: Re: [Mingw-users] Fork Frare, Steven A (Steven) wrote: > Hi: >=20 > I am a newbie here so please forgive my ignorance. >=20 > I have downloaded all that I think I need to but still can not find = fork(); >=20 > Where is fork implemented? What source file can I look at? >=20 > Thank You > Steve >=20 Steve, fork() is a Unix-ism. MinGW is for compiling Windows programs. Perhaps = you want something along the lines of a Linux-like environment for=20 Windows, in which case you might try Cygwin or coLinux. Perhaps you=20 want a Windows call along the lines of CreateProcess. --Andrew ------------------------------------------------------- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_id=3D5588&alloc_id=3D12065&op=3Dclick _______________________________________________ MinGW-users mailing list Min...@li... You may change your MinGW Account Options or unsubscribe at: https://lists.sourceforge.net/lists/listinfo/mingw-users |
From: Frare, S. A \(Steven\) <st...@av...> - 2004-11-07 18:19:33
|
Hi Michael: Okay, thanks. Just was praying this had fork. Due to the licensing of = Cygwin I can't use it, so I will still be hunting something down. = Writing fork is non-trivial, and while I am working on it it is slow = going. I would prefer to use threads and hope(d) to pull fork out and = put threads in after a successful first pass... I may have to re-think = that strategy! ;-> Thanks Again! Steve -----Original Message----- From: min...@li... [mailto:min...@li...]On Behalf Of Michael Gerdau Sent: Sunday, November 07, 2004 9:11 AM To: min...@li... Subject: Re: [Mingw-users] Fork Hi Steve ! > however my understanding was that MinGW supported Unix calls to > aid in porting Unix apps to Windows, in which case the fork() > function call is often used. =20 Here your understanding is wrong. MinGW aims to replace or at least be compatible with VC++ and of course interface with the Win32 environment as good as possible. If you are looking for a Unix-like environment on Win32 than probably cygwin is what you are looking for. > Unfortunately CreateProcess and it's friends do not provide > similar behavior to that of fork and aren't a good replacement. =20 Not knowing the exact problem I am in a poor position to judge however I always considered fork() a last resort when you don't have proper threads. I understand there is a lot of legacy code on Unix which uses fork() for things which actually mean threads. And ranting about the shortcomings of fork() by no means helps when porting such software... Anyway: Any true fork() on Win32 would have to be implemented by use of CreateProcess and it's friends. If you really need fork() then you'll probably have to provide the missing bits by writing our wrapper around CreateProcess. If you are in a position to choose you should consider using threads though. Best, Michael --=20 Vote against SPAM - see http://www.politik-digital.de/spam/ Michael Gerdau email: mg...@te... GPG-keys available on request or at public keyserver ------------------------------------------------------- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_id=3D5588&alloc_id=3D12065&op=3Dclick _______________________________________________ MinGW-users mailing list Min...@li... You may change your MinGW Account Options or unsubscribe at: https://lists.sourceforge.net/lists/listinfo/mingw-users |
From: Keith M. <kei...@to...> - 2004-11-08 09:48:42
|
> Okay, thanks. Just was praying this had fork. > Due to the licensing of Cygwin I can't use it, so I will still > be hunting something down. Writing fork is non-trivial, and > while I am working on it it is slow going. I would prefer to > use threads and hope(d) to pull fork out and put threads in > after a successful first pass... I may have to re-think > that strategy! ;-> Hi Steve, If the UNIX app you are porting has code like child = fork(); if( child == 0 ) { . . exec...( ... ); . } you could consider using spawn...( ... ) to replace everything from the fork() call down to the exec...() call -- there is a spawn family function corresponding to each of the members of the exec family, e.g. fork() ... execlp( ... ). This is generally the easiest way to port such applications. There are, however, a few caveats: 1) Any initialisation done between the fork() and exec() calls, in the UNIX code for the child process, needs to done *before* the spawn() call -- i.e. in the parent process. This uaually means saving parent process context, setting up the context to be passed to the child, which is created by the spawn(), then restoring the saved parent context. 2) There is one additional argument to spawn(), when compared with the corresponding exec() call -- the first argument specifies a "concurrency mode", (typically a manifest constant defined in process.h, e.g. _P_WAIT or _P_NOWAIT, or see MSDN for other options). 3) Argument quoting does not work correctly -- if you try to pass arguments which contain embedded white space, then they will be split into extra arguments at the spaces. This is a limitation of Microsoft's CreateProcess function, which spawn ultimately uses. To work around it, you need to add literal double quote characters into the argument vector, to protect the white space. (I have a GPL library of spawn() and exec() wrapper functions, which I wrote for the GNU troff project, and which do this transparently -- I can let you have a copy *if* your use is GPL compliant, (which perhaps it isn't, if you can't use Cygwin)). HTH. -- Regards, Keith. |
From: Zuxy <zu...@bj...> - 2004-11-08 14:57:58
|
----- Original Message ----- Subject: RE: [Mingw-users] Fork Date: Sun, 7 Nov 2004 07:37:11 -0700 From: "Frare, Steven A \(Steven\)" <st...@av...> To: <min...@li...> > I realize fork is a Unix-ism, however my understanding was that MinGW > supported Unix calls to aid in porting Unix apps to Windows, in which > case the fork() function call is often used. MinGW is mainly a compilers' package, not a *nix-like environment for cross-platform compilation. MSYS is, however, but it only provides limited capability. For porting *nix apps to Windows, you should look for Glibc for Windows at gnuwin32.sourceforge.net, which ports a subset of glibc functions to native Windows, not including fork(), though. > Unfortunately CreateProcess and it's friends do not provide similar > behavior to that of fork and aren't a good replacement. Windows' process management differs significantly from that of *nix, and it's nearly impossible to port it to Windows natively without an intermediate layer:-( -- Zuxy Beauty is truth, While truth is beauty. |
From: Michael G. <mg...@te...> - 2004-11-07 17:10:52
|
Hi Steve ! > however my understanding was that MinGW supported Unix calls to > aid in porting Unix apps to Windows, in which case the fork() > function call is often used. Here your understanding is wrong. MinGW aims to replace or at least be compatible with VC++ and of course interface with the Win32 environment as good as possible. If you are looking for a Unix-like environment on Win32 than probably cygwin is what you are looking for. > Unfortunately CreateProcess and it's friends do not provide > similar behavior to that of fork and aren't a good replacement. Not knowing the exact problem I am in a poor position to judge however I always considered fork() a last resort when you don't have proper threads. I understand there is a lot of legacy code on Unix which uses fork() for things which actually mean threads. And ranting about the shortcomings of fork() by no means helps when porting such software... Anyway: Any true fork() on Win32 would have to be implemented by use of CreateProcess and it's friends. If you really need fork() then you'll probably have to provide the missing bits by writing our wrapper around CreateProcess. If you are in a position to choose you should consider using threads though. Best, Michael -- Vote against SPAM - see http://www.politik-digital.de/spam/ Michael Gerdau email: mg...@te... GPG-keys available on request or at public keyserver |