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.
> 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.
> 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.
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.
> 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.
> 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.
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):
-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)
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?
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.
> 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 :-)
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.
Cheers,
Jon
--
"May their negative actions ripen upon me. And may all my virtues ripen upon
them."
"If it could be talked about, everybody would have told their brother."
[EMAIL PROTECTED] , [EMAIL PROTECTED]
