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:
-Test suites are only of interest to the dll developers. They don't give
other developers any useful code examples, or users any functionality.
-The suite will be *big*. I cleaned up my harness to be easier to add to, and
diff crt's better (show the differences and the test line number they occur
at). I've only moved 95 (out of 520+ for crtdll,800+ for msvcrt) tests into
it so far and its already 2,200 lines. I project 15,000+ lines in total by
the time its 'finished'.
-In order to test some functionality (spawn/system etc) and work consistently
on every developers setup, the suite must include extra files. These will
need to be distributed with the harness in binary form.
-The harness must also create/write/delete files and directories. This is
better done outside of the wine tree IMO.
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).
> 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...
> 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).
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.
Note: the following is not a flame, just observations:
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).
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.
cabs:
-functionally identical to crtdll. for source compatability the members of
the complex struct should be called "real" and "imaginary", not x & y.
-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.
_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).
-main.c - you left some (old) crtdll calls in there ;-)
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.
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.
Finally, if you are going to change/resend the tarball, can you "make clean"
before you do? I'm on a 56k connection here :-(
> 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...
> 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.
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
