On March 31, 2003 11:31 pm, Alexandre Julliard wrote:
Yes, it's just that I don't like to add non-Unix APIs to the
portability layer, but I guess there are good reasons for making
an exception here.
I agree -- adding non-Unix APIs is not a good idea. 100% with you.
But this one is one
Dimitrie O. Paun [EMAIL PROTECTED] writes:
OK, here's a patch to add _spawnvp to the portability lib. There
are still a few questions:
-- Should we provide the entire family (I wouldn't, unless we
really need them, but that can wait for that need :))?
Yep that can wait.
-- What
On 1 Apr 2003, Alexandre Julliard wrote:
If they link with msvcrt then they are not supposed to use
wine/port.h. To avoid trouble with process.c I'd suggest naming the
function spawnvp, without the underscore prefix, and making it call
the real _spawnvp on Windows.
Cool. Here it is again.
On March 31, 2003 07:12 pm, Alexandre Julliard wrote:
Log message:
Use _spawnvp to replace fork for non-Unix platforms.
What about adding it to the portability lib? I can do the patch
if you want...
--
Dimi.
Dimitrie O. Paun [EMAIL PROTECTED] writes:
What about adding it to the portability lib? I can do the patch
if you want...
I'm not sure about that; it would be somewhat cleaner, but OTOH I'm
not sure I like the idea of adding DOS functions in the portability
layer...
--
Alexandre Julliard
On March 31, 2003 10:20 pm, Alexandre Julliard wrote:
I'm not sure about that; it would be somewhat cleaner, but OTOH I'm
not sure I like the idea of adding DOS functions in the portability
layer...
However, if we are to depend on winegcc/winewrap, we need to be able
to compile it anyway, no?
Dimitrie O. Paun [EMAIL PROTECTED] writes:
However, if we are to depend on winegcc/winewrap, we need to be able
to compile it anyway, no? And since it has a well defined semantics
(that's much more commonly available than the fork/exec), it's not
necessarily a bad addition.
Yes, it's just
