[prev in list] [next in list] [prev in thread] [next in thread] 

List:       wine-devel
Subject:    Re: MSVCRT
From:       David Elliott <dfe () infinite-internet ! net>
Date:       2000-12-31 8:04:16
[Download RAW message or body]

Jon Griffiths wrote:

> Hi,
>
> > Definitely, I am not sure how to go about this now though.  Should we just
> > say the hell with it and forward to CRTDLL since our CRTDLL is working
> > better or should we just move code out of CRTDLL and into MSVCRT a function
> > at a time (or several at a time)?  I would prefer sticking with the latter
> > as previously discussed, CRTDLL should depend on MSVCRT and not the other
> > way around.
>
> I think the better plan is your original one, that is, to move everything
> into MSVCRT (principaly to avoid dependency issues). But we can't really do
> this a function (or even a couple) at a time, things need to be moved in
> (generally large) related blocks because of data dependencies (e.g we dont
> want 2 _iob's being used). more on this below.
>

Yes, I thought about that, especially with relation to functions that are
different for each DLL but use data that may need to be common.

>
> > Actually yes, my original focus, and my main goal is not to churn out tons
> > of function implementations, but to provide a build environment with proper
> > headers and an example of how to make a Winelib app that uses MSVCRT or
> > CRTDLL as its C library.
>
> Yeah, I think we really need this, especially for Unicode, which is
> impossible to work with using libc.
>
> > Well, the phrase "atexit is limited only by available memory" lead me to
> > decide that a linked list would be better, plus since they go in LIFO order
> > it just seemed to make sense.
>
> Sure. Dont get me wrong, IMO your implementation of the storage was more
> correct. I just meant that with the huge number of functions left to
> implement (350+!) it might be more useful to get things working first and
> take care of the extreme cases later.
>

Sorry, also forgot to mention that I had written it before your implementation,
or probably at the same time, but you released first, so I wasn't trying to
duplicate work or provide a better implementation of a trivial thing, I just
happened to implement it that way when I did it.

>
> > Okay, I swear that's what MSDN said, but you know MSDN.  Or maybe I pulled
> > that out of a UNIX header because it didn't say anything and at the time I
> > didn't have UNIX headers handy.
>

(whoops s/UNIX/windows/ on that last line)

>
> Nope, you were right, I was tripping :-) too much coffee I think, sorry!
>

;-)

>
> > Hmm, okay, I tried to come up with a way that could easily translate most
> > windows errors into UNIX errors and fallback to a default value for that
> > particular function if there was some other error.  I would appreciate
> > suggestions.
>
> Hmm, we really want to translate to MS errnos rather than Unix. The current
> method is correct for errno/doserrno in over a hundred functions Ive tested
> error cases for, so I think it should do for now. There are a few cases were
> the error is set/cleared explicitly as well, when errno is set but doserrno
> isn't (these are pretty easy to test and usually listed in the online docs).
>
> > If you notice, the functions I implemented are pretty basic, like exit
> > handling and printf (not even implemented correctly).  The forwarding to
> > NTDLL was how it was done in the original CRTDLL so I just kept it so that
> > the functions would remain implemented in MSVCRT.  Basically I just wanted
> > to get the DLL in the tree so I could link Winelib programs against it.
>
> OK, specmaker will generate (+ install into the Wine tree) a suitable stub
> for people in about 30s if all they want to do is link. So we can probably
> hold off putting the actuall DLL into the tree until we move the code, the
> headers are more important. But mainly the code has moved on _a lot_ since
> you grabbed it, especially in the area of initialisation/exit/cleanup, which
> is why I didn't think an msvcrt dll based on it should go in.
>

Right, might want to hold off until we stabalize and get ready, I can live with
that figuring that now that linking works correctly I can just link against
CRTDLL! (woohoo!)

>
> > I can still go ahead and
> > get a good set of working header files together for winelib.  When I have
> > all the implemented functions prototyped in the correct headers (which
> > shouldn't take too long, just kind of tedious)
>
> That would be very useful (you're right about it being tedious though). lcc
> has very clean headers if your looking for a place to start (the MS ones seem
> to be full of useless chuff). Except for wchar.h, a lot of the libc headers
> can be used as well.
>

I actually have mostly stayed away from MS headers, easier to prove it wasn't a
derived work that way.  Only in few cases where MSDN is vague in which case they
are documentation and not copied code.  Better safe than sorry I figure.

>
> > then I should start working
> > on implementing what has not been implemented yet.
> > Hopefully now we both have the time to work on this together.
>
> Absolutely. Theres a ton of functions to implement, many months work for
> several people I think.
>

Oh definitely.

>
> I have started working on moving crtdll into msvcrt and am probably a couple
> of days away from submitting it (i.e as soon as I get wordpad to run :-)
> I made *a lot* of changes to the crtdll code to do so (this list dumped
> straight from my change notes, excuse spelling):
>

hehe Wordpad, move over solitaire, there's a new regression testsuite for Wine...
I like it ;-)

>
> -Add thread local storage for previously process global variables (errno etc)
> - Mostly MT safe (could be more fine grained, but go for safety first)
> -Code re-org:
>  +Strip uneeded chuff, share only the definitions we need
>  +Move types into units that use them
>  +Standardise names, use the same types as windows
>  +Where we need libc headers, bring them in as late as we can (eventually
>   want to remove as many as possible)
>  +Compile -Wall, -W clean
> -Fix up spec entries for str/ptr/wstr (werent always correct)
> -Add spec comments for stubs w/parameters we know about
> -Added/fixed some functions:
>  +set/query_new_mode
>  +Implement some wide char file/dir functions
>  +cprintf/vfprintf now handle any length of output
>  +Print exit errors to console, not stdout
>  +Remove extern printf in spec (cant use libc for this)
>  +Use windows errno values
>  +Ensure Getmainargs is called even for Winelib apps
>  +Add some DLL data query functions
>  +start of binary compatable c++ constructor code for native apps (MFC)
>

Sounds good.

>
> Basically I want to ensure that if we are going to cause disruptions for
> people (which we will, undoubtably people arent going to read the release
> notes and will run the builtin), then its for a worthwhile reason (i.e. an
> msvcrt that can actually run some programs). How about I send you what I've
> done so far, and we can pick the areas were interested in working on?
>

Yup, sounds cool, send away.

>
> I'm not adverse to doing some of the headers, and I really dont want to
> monopolise the code either. I am adding the constructor code (the first ~30
> mangled exports), and I should probably be the one to turn crtdll into a
> forward DLL as well, since Ive encountered a few tricky things while moving
> the code that will need to be adressed. Other than that I have no preferences
> as to which parts of msvcrt I work on. With two of us hacking on it we should
> be able to make great progress. Let me know and I'll mail you a current patch.
>

I hear you there, go ahead and mail it, I have a cable modem so if you don't mind
uploading it I don't mind downloading it.

>
> > Very cool, my "testsuite" was more of a "Hello World" which may be
> > beneficial to include in the main Wine tree just to show the basics of
> > linking to a CRTDLL and using Wine's headers instead of UNIX headers.
>
> Sure thing. I think as soon as we can manage it, _all_ sample programs in the
> tree should move to msvcrt; that way if we break anything along the way we'll
> know about it sooner rather than later :-)
>

That probably is a good idea also so they can be compiled under both normal
Windows and Wine without modification.

>
> I havent fully updated mine yet, since I need to get msvcrt working with MFC
> apps, but if you want a copy as well let me know. Since its LoadLibrary based
> it really doesn't belong in the tree, but it will be useful for regression
> testing as it gets expanded.
>

As mentioned before, we may want to think of a seperate CVS containing test
suites.

>
> Cheers,
> Jon
>

Good day,
-Dave

[prev in list] [next in list] [prev in thread] [next in thread]