Uwe Bonnes wrote:
> Andreas Mohr writes:
> > On Sun, Jul 16, 2000 at 03:44:16PM +0200, Uwe Bonnes wrote:
> > > Hallo,
> > >
> > > is there any reason to further work on wine crtdll? Running e.g. a
> > > MingW programm needs a lot more functions in crtdll. Running with a
> > > native crtdkk however makes the program work.
> > >
> > > If crtdll is distributed with applications, I think we can drop it.
> > >
> > > Opinions?
> > Yes.
> > We cannot drop it.
> > I didn't know that native CRTDLL works.
> > But where it doesn't work (AFAIK - correct me if I'm wrong) is the
> > file handle problem (the internal struct order is different).
> > This needs to be solved, and of course this has to happen in the
> > builtin CRTDLL.
> >
> Hallo,
>
> no quick shots :-)
>
> CRTDLL isn't a low level DLL like NTDLL. Many thinks that don't work
> with wine crtdll work with native crtdll. File handling is done
> through Api Calls into Kernel/User and so even the file handle problem
> shouldn't exist.
>
> A scan through native CRTDLL on my system lists 622 exported APIs. And
> especially Cygwin/MingW programs use a lot of them...
>
Hmm, implementing this could be a problem-- not the implementation, but the
flamewar^H^H^H^H^H^H^H^Hdiscussion I am about to start. I think this has
been talked about before but here goes anyway.
Okay, there are three ways that I can think of to implement CRTDLL
1. Use Win32 APIs exclusively
This would be a lot of work, but we wind up with a CRTDLL that is much more
portable because it only requires Wine and not UNIX
2. Use UNIX APIs exclusively
That is, for every CRTDLL function, go direclty to the standard function.
Don't think this is very desirable because there are problems with
file-handles and stuff.
3. Use a mixture
This is probably the most viable option. Use Win32 when possible, use
native UNIX when it can be correctly implemented simply by calling down to
UNIX C library. Unfortunately, the functions which use UNIX will need to be
changed if they are to be used in other Windows on whateve projects, of
course, that is not really our problem either! Of course if someone
actually *wants* the extra work of making it Win32 exclusive, they can have
it!
-Dave
