August 2003 - Wine-Devel - list.winehq.org

Re: Wine 0.9 progress

by Vincent Béron

Le ven 29/08/2003 à 20:13, Dustin Navea a écrit : > so without the xp server flavors and all the 2k3 flavors, we have 16.. even > if we simplify to nt4, and 2k, its still a dozen like you originally said, > although if you take out the osr's then it would be 8, but there are a couple > of service packs and osr's and things of that nature that im sure changed > some things that would affect the conformance test suite.. either way, we > need to have 16 people for at least the first run (or a few people with > multiple os's on their comps) to find out which service packs and which > flavours of the nt based windows' actually have changed things, to where we > would need to continue to run a test on those specific service packs, etc.. > confused yet? I follow. The problem with this is we'll need the 16 for longer than only the initial run, as not all API have a conformance test yet. If it's not tested, we don't know if it changed or not. > > say nt4's sp3 and sp6 changed some stuff that would affect the results of the > conformance tests. we would do the first run on all nt service packs > (finding them all would be another story, though). then we would discover > that nt4 reg, sp3, and sp6 gave different results on the tests, so we would > run subsequent tests on only those 3, thereby eliminating about 7 other tests > (sp1, 2, 3a, 4, 5, 6a, etc) Overkill. Wine advertises NT4 SP6 only, not the other SPs. Same thing for each major version, only one SP match. So there's little point in conforming to something not supported by Wine, as it's been superceded. Future SPs will be tested as a "new" version, and if conformance tests fails on them, then it'll be fixing time (conformance test, plus Wine if applicable). Vincent

Aug. 30, 2003

Re: [dcom 1.1] Implement dispatch variant marshalling

by Alexandre Julliard

Mike Hearn <mike(a)theoretic.com> writes: > + working_mem = GlobalAlloc(0, size); > + assert( working_mem != NULL ); > + > + hr = CreateStreamOnHGlobal(working_mem, FALSE, &working); > + assert( hr == S_OK ); > + > + hr = CoMarshalInterface(working, &IID_IDispatch, (IUnknown*)V_DISPATCH(pvar), LOWORD(*pFlags), NULL, MSHLFLAGS_NORMAL); > + assert( hr == S_OK ); Please don't use assert for error checking. Errors should be either handled properly or propagated to the caller. -- Alexandre Julliard julliard(a)winehq.com

Aug. 30, 2003

Re: Wine 0.9 progress

by Dustin Navea

--- "puoti(a)inwind.it" <puoti(a)inwind.it> wrote: > I think Francois is right, there are only about a dozen versions of > windows, if > you count the various win95osr1, osr2, 98se and so on, and probably the > running > the tests only on the major releases of windows (8 if you count xp home > and > pro), so all that is needed is 8 people that run these tests and send a > mail to > this list when something that did work breaks. > > > Actually there are quite a few more than 8, even not including service packs on 2000 and xp and nt.. 95reg, osr1, osr2, osr2.1, osr2.5, 98, 98se, me, nt4w, nt4s, 2kpro, server, adv server, datacenter server, xp home, xp pro, and im not sure what the xp server flavors are called, but i know there are a couple of those.. plus 2k3 so without the xp server flavors and all the 2k3 flavors, we have 16.. even if we simplify to nt4, and 2k, its still a dozen like you originally said, although if you take out the osr's then it would be 8, but there are a couple of service packs and osr's and things of that nature that im sure changed some things that would affect the conformance test suite.. either way, we need to have 16 people for at least the first run (or a few people with multiple os's on their comps) to find out which service packs and which flavours of the nt based windows' actually have changed things, to where we would need to continue to run a test on those specific service packs, etc.. confused yet? say nt4's sp3 and sp6 changed some stuff that would affect the results of the conformance tests. we would do the first run on all nt service packs (finding them all would be another story, though). then we would discover that nt4 reg, sp3, and sp6 gave different results on the tests, so we would run subsequent tests on only those 3, thereby eliminating about 7 other tests (sp1, 2, 3a, 4, 5, 6a, etc) hope that clarifies some stuff, and helps out someone.. ===== -- Dustin Navea Minor Contributor, http://www.winehq.com Bugzilla Janitor, http://bugs.winehq.com Network Admin, irc://irc.blynk.net (down) __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com

Aug. 30, 2003

Re: Wine 0.9 progress

by Jakob Eriksson

Francois Gouget wrote: >Do we really need a C program, a new mailing list, automated result >submission, generating HTML and now a database just so we have something >that says: > >Test | Result >----------+--------- >kernel32 | Passed >msvcrt | Passed >oleaut32 | Passed >dsound | Passed >... > >This all seems very much over-engineered to me. I'd really like to see >that kind of energy spent on fixing the tests so that they actually work >on Windows. > > Well, a new mailing list seems overkill to me. Since yesterday I have been working on a program to run the tests. I have it more than 50% done now. It runs all the tests and logs everything in a file. The test is one big EXE for the Windows tester to download. The reporting is uploaded automatically if the user wants to. The EXE is built with mingw crosscompiler, so no need for MSVC. regards, Jakob

Aug. 29, 2003

Re: [winecfg 1.1] Implement saveConfigValue(), style changes, code cleanup, UI alignment

by Dustin Navea

--- Francois Gouget <fgouget(a)free.fr> wrote: > On Thu, 28 Aug 2003, Alexandre Julliard wrote: > [...] > > Also once the config is in the registry it becomes inconvenient to > > modify by hand > [...] > > That's one thing that bothers me with moving the configuration data to > the registry: in the registry you cannot put comments that document what > an option does. More precisely, comments are not preserved when > wineserver saves the registry so adding comments is an exercise in > futility. > > The Unix way is to have text configuration files that are > self-documented. Not all projects are born equal on this point of > course, but look at squid.conf, smb.conf our even our own Wine > configuration file for instance. > > The Windows way is to have obscure binary parameters in the registry and > force you to buy a dozen book to know what 1% of them are for. I.e. most > of the options are completely undocumented. > > I'm afraid moving the Wine configuration will move us towards the > Windows model which is IMO not a model to follow. > > Is there a way to use the registry (as seems to be required for many > features) and still document our settings correctly? Maybe add a 'Doc' > value for each regular value: > > [SomeKey] > OptionFoo=1 > OptionFooDoc="OptionFoo does this, that, etc." > > Better ideas? > > Not sure how possible this is or if it has already been thought of just let me know, but what about loading the config into memory and having wine make it look like the registry while loaded (ie for windows regedit). wine can do the processing of both the registry and the config, and then when it is time to save the changes done in regedit, wine sorts it out between what needs to be written to the actual registry and what needs to be written to the config file. That way we have the registry, but we can keep the traditional unix (and all variants) plaintext config file, with documentation for the more advanced users, but if an end user wants to edit the config thru the registry, he can.. Of course winelib regedit should be modified to load the config file and make it look like standard registry keys as well, if it doesnt already, for the people willing to forego installing/copying a ms program (ie windows regedit) on their linux partitions.. lol Comments/Flames/Suggestions? ===== -- Dustin Navea Minor Contributor, http://www.winehq.com Bugzilla Janitor, http://bugs.winehq.com Network Admin, irc://irc.blynk.net (down) __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com

Aug. 29, 2003

Re: [resend] Allow use of MAP_TRYFIXED for better mmap()

by Todd Vierling

On Fri, 29 Aug 2003, Dustin Navea wrote: : Shouldnt something like this added to the loader work for a runtime check? : (note im not using proper function names or anything, just an example) : : if (running_on_netbsd && version >= first_version_that_supports_MAP_TRYFIXED) : #define can_use_MAP_TRYFIXED That kind of OS dependency runtime check does not belong in an application that runs on multiple OS's. In every sane application, both "running_on_netbsd" AND "version" are constants, so the test is either always true or always false. What it comes down to is this: NetBSD doesn't do all the kernel and libc shuffling of Linux. Its version numbers are quite well defined, and it's trivial to state what version was used to compile a binary. So the patch is Just Fine as-is, and needs no further pollution. -- -- Todd Vierling <tv(a)pobox.com>

Aug. 29, 2003

Re: [resend] Allow use of MAP_TRYFIXED for better mmap()

by Dustin Navea

--- Todd Vierling <tv(a)pobox.com> wrote: > On Thu, 28 Aug 2003, Alexandre Julliard wrote: > > : > I have a feeling we're just on different mental wavelengths here. > : > MAP_TRYFIXED is not an optional feature. If the #define exists, the > feature > : > exists -- for the OS version used to compile, and all later versions. > : > : You are still thinking only about source distributions. The problem is > : when you want to ship a binary: the only way to build a binary that > : works for everybody is to build it on an old OS version; > > Yes, that's right. This is not a problem, as 99% of Wine users on NetBSD > are building from source. The very small remainder of prebuilt-binary > users > can easily be told to ensure that the OS version is up-to-date (since there > are security fixes that necessitate this anyway). > > : With a run-time check you don't have to sacrifice anything, > > You have to bend over backwards to do the runtime check, and you sacrifice > *maintainability* with the extra normally-dead code added to Wine. I don't > see a need to jump through extra hoops in this case. Shouldnt something like this added to the loader work for a runtime check? (note im not using proper function names or anything, just an example) if (running_on_netbsd && version >= first_version_that_supports_MAP_TRYFIXED) #define can_use_MAP_TRYFIXED Im no expert on NetBSD but I would think a simple check like that would suffice, and since it is in the loader, it would make it a runtime check, no? ===== -- Dustin Navea Minor Contributor, http://www.winehq.com Bugzilla Janitor, http://bugs.winehq.com Network Admin, irc://irc.blynk.net (down) __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com

Aug. 29, 2003

[ANN] Conformance testing campaign

by Ferenc Wagner

Greetings! Hereby I ask people who have access to real Windows machines to help me gather information about the behaviour of cross- compiled conformance tests on the different platforms. Please go to http://afavant.elte.hu/~wferi/wine for details. If you can build the tests in the Wine tree by MSVC, then packaging the compiled binaries would also mean a valuable addition. You will also find a packaging script on the page. Thanks for your time, Feri.

Aug. 29, 2003

Re: Wine 0.9 progress

by puoti＠inwind.it

Probably a batch script that runs all the tests and outputs the results to a file can do, but this a C program, a new mailing list, automated result submission, generating HTML and now a database for something that says: Test | Result ----------+--------- kernel32 | Passed msvcrt | Passed oleaut32 | Passed dsound | Passed seems a big exaggeration

Aug. 29, 2003

Re: Wine 0.9 progress

by puoti＠inwind.it

I think Francois is right, there are only about a dozen versions of windows, if you count the various win95osr1, osr2, 98se and so on, and probably the running the tests only on the major releases of windows (8 if you count xp home and pro), so all that is needed is 8 people that run these tests and send a mail to this list when something that did work breaks.

Aug. 29, 2003