First off, sorry for the late response, I just got back from vacation and was
planning to do some Wine work during but I wound up having enough computer stuff
to do fixing my parents computers.
Jon wrote:
> Sorry for the long post, theres a few issues raised here...
>
> On Monday 18 December 2000 9:07 am, David Elliott wrote:
> > > I am not yet including the testsuite in programs/msvcrttest but I will
> > > be posting that to wine-devel with an explanation shortly.
>
> I have a test harness for crtdll/msvcrt (or any other crts e.g.
> borland/watcom) that I've been using to test the crtdll implmentation against
> both dlls. I'd suggest we *not* put testsuites in programs/whatever (or in
> fact into the wine distribution at all), for the following reasons:
>
>
[SNIP]
Well the "testsuite" in its current form is just a printf and exit so I am not
doing duplicate work, it was more of a test to make sure it was loading the
DLL the way I expected it to (which Wine now does).
>
> What I propose is distributing test harnesses seperately (e.g. as a tarball).
> In this way developers who want to work on a given dll can d/l the
> testharness to check they dont break anything, and add tests for new
> functionality they add without disturbing the regular wine development, or
> increasing the download time any more for people getting/updating Wine.
>
> For reference, the crtdiff options output is attached to the end of this
> message. I can upload it to the wine patches directory if anyone is
> interested in looking running it (its a Winemaker-generated project that sits
> outside the Wine tree).
>
A separate tarball would probably be the way to go for all the testing stuff.
It should have its own CVS as well.
>
> > Possibly because it is against current CVS and you are at the last release?
> > There have been lots of changes to that file.
>
> I'm on the latest cvs and it failed for me too. Might have been chomped by
> the mailer...
>
Doubt it, I am using netscape and attaching the file. I'll take a look at it
again now. Also, saw in another mail I forgot to do a make clean directly
before packaging it up... that's because I did a make just before to make sure
it compiled okay.
>
> > Right now I am just trying to get MSVCRT into the tree so I can start
> > producing normal patches to implement all of the features. You may have
> > noticed the big fat warning (fixme actually) during the initial load of
> > MSVCRT.
>
> I suggest you don't bother reimplimenting the msvcrt functions that are
> already in crtdll. Every function I've tested so far in crtdll is exactly the
> same as msvcrt, except for about 6, which differ only in that the crtdll
> implementation is broken. e.g.
> -some math functions don't set EDOM in crtdll but do in msvcrt.
> -setlocale is a superset of functionality in msvcrt (e.g. locale aliases are
> supported).
>
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.
>
> In these cases its better to implement the msvcrt functionality because it is
> essentially a bug fixed & MT safe version of crtdll. I have done this but
> haven't added MT safety since Alexandre didn't want to when I started out.
>
> I am planning to move crtdll into msvcrt pretty shortly and turn crtdll into
> a forwarding dll, as per the discussion(s) a couple of months ago (I may add
> a dll 'alias' facility to .wine/config instead of creating a forward dll, and
> remove crtdll completely. This will allow us to mimic other crts also). I'll
> be submitting a patch in a few hours that takes crtdll completion to above
> 80%. This represents about 40% of msvcrt (which contains all of crtdlls
> functionality and extends it). I estimate that the time to then make the
> functions threadsafe will be around a week, at which point winelibbers can
> start trying msvcrt out with their apps (providing they dont use UNICODE, see
> below), and we can start on the other 60%...
>
> IMHO, It would be much more productive for you to work on functions that
> haven't already been implemented, or that occur in msvcrt exclusively. It is
> going to be a large job completing msvcrt and working in different
> areas will allow a Winelib version to progress a lot faster. Since I will be
> working on msvcrt once the code shift is done, I would *really* like not to
> fix functions I have already implimented.
>
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.
>
> Note: the following is not a flame, just observations:
And not taken as a flame either.
>
> Every implemented function in your patch is already implemented for crtdll.
> Aside from atexit being MT-safe there seems little point in the duplication
> (I don't know any apps that make more than 20 atexit calls for instance).
>
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.
>
> Some other issues that I see:
> onexit/atexit: "/* MSDN does not mention setting errno on fail */"
> -malloc sets errno, you should save and restore it if you *really* dont want
> to set it. Exit processing is far advanced in cvs crtdll anyway, and
> superceeds this implementation (open files are flushed/temp files are removed
> etc). Also, atexit() can be implemented as a one line call to onexit, no need
> for the duplication.
Well, onexit functions return an int, atexit functions don't. So my original
thinking is why the hell would you make a specific case for returning a value if
you weren't going to use it. Therefore I thought it would be better if when
going through and running them it could tell the difference between them.
However I think I tried returning some different values to a real MSVCRT and it
had no effect and I didn't see any specific things in the docs, so in that case
then definitely.
>
> cabs:
> -functionally identical to crtdll. for source compatability the members of
> the complex struct should be called "real" and "imaginary", not x & y.
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.
>
> -errno stuff - some cases don't set errno consistently for a given win error,
> some cases only set errno and no doserrno. this needs to be reworked.
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.
>
> _CIpow :
> -You cant forward this to ntdll, ntdll doesnt know about crtdll errno (try
> calling it with NaN as an argument, and checking errno after return, or check
> the crtdll implementation).
Noted.
>
> -main.c - you left some (old) crtdll calls in there ;-)
>
damnit.
>
> I raise the above only to point out how reworking already implemented stuff
> is a waste of both of our time. If you can wait for about a week, I can move
> crtdll into msvcrt and give a solid base to continue developing on. Then we
> could coordinate which areas we are interested in so we don't trip each other
> up.
>
Yes, absolutely. What has happened is that you are essentially looking at a
copy of CRTDLL from when I split it off before you had done anything with it.
So it still has all the same issues as before.
>
> I suggest that the patch go in with the .spec and a dummy main.c (i.e. the
> broken/duplicate code removed), and I'll focus on moving crtdll into it as
> soon as its committed. Hopefully thats acceptable. It means, as you said,
> that winelibbers can start linking with native msvc, which is a very valuable
> addition to Wine.
>
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.
>
> Finally, if you are going to change/resend the tarball, can you "make clean"
> before you do? I'm on a 56k connection here :-(
>
Sorry, I explained that above (Thought that was in a later mail from lawson, but
I guess it was just further down on this long mail).
>
> > Hopefully that will take care of any problems with people having
> > builtin before native for the default load order.
>
> We should add mscvrt = native to wine.ini and put a *big* warning into the
> next release announce if the patch goes in IMHO. Only developers will want to
> use wines msvcrt for at least the next few months. A large number of new
> users just dont RTFM, and bugs could ruin the execellent application progress
> made so far...
>
Yeah, that's probably a good idea. There is a big warning when the dll main
function loads for that very reason, but I guess it is not enough.
>
> > Alternatively you could link the winelib program against the somewhat more
> > implemented CRTDLL using the same prototypes.
>
> You dont even need to prototype if you don't mind the warnings, winebuild
> will resolve the symbols provided you "import crtdll" in your apps .spec file
> (and you dont use any types you dont have definitions for). The only area
> where this won't work currently is with UNICODE apps, or if you do anything
> tricky with threads, since crtdll isn't yet threadsafe. Francois Gouget is
> currently working on getting unicode to work for Winelib. Linking to native
> msvcrt is essential for that.
>
Okay, as I see it you have been doing some great work implementing all of the
functions and knocking them out at lightning speed. I unfortunately got started
and had some higher priority things to work on and therefore kind of let the
code rot for too long. However even without a working MSVCRT (which you are
free to deal with since it is mostly your code and you will know better how to
move over to MSVCRT) 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) 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.
>
> I guess we could use some words of wisdom on proceeding. Anyone?
>
> Cheers,
> Jon
>
> ---Sample crtdiff output ---------------------
> [jon@beast crtdiff]# ./crtdiff
> crtdiff:Invalid arguments.
> Usage: crtdiff [-i] [-o[b]] [-p] [-c n] [-s] dll-1 dll-2
> Print differences between two crt DLLs.
> Arguments:
> -i Perform (I)nteractive tests (e.g console, default: Don't)
> -o[b] Use mscvrt (O)rdinals for dll-2, b = for both (default:crtdll)
> -p (P)rint all output (default:Diffs only)
> -c n (C)all terminating function n (Max 3)
> Note: Skips other tests and calls the first dll only.
> -s (S)kip tests that are known to (validly) differ.
> dll-1 Name of source DLL
> dll-2 Name of DLL to compare
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.
Have a good one,
-Dave
