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

Cabinet.dll documentation

by Steven Edwards

Hello Are the cabinet stuctures and defines documented anywhere online? I tried to submit the WINE headers to mingw for use in w32api but they couldnt find documents on it anywhere. All I could find was the cabinet SDK and they has a EULA attached so I am not looking at it. Thanks Steven __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com

Aug. 28, 2003

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

by Francois Gouget

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? -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ tcA thgirypoC muinelliM latigiD eht detaloiv tsuj evah uoY

Aug. 28, 2003

Re: Wine 0.9 progress

by Jeremy Newman

On Thu, 2003-08-28 at 16:47, Dimitrie O. Paun wrote: > So yeah, now the focus should be in post-processing these results. > Also, Jeremy can we setup a mailing lists/alias to where > the results should be sent? This way we have a well-known entry > point (e.g. wine-tests-results(a)winehq.org) and we've broken down > the problem into simpler parts: Sure, if that is the address you want for the list I can probably put it up tomorrow sometime. I just want to be very sure before I start work on it. > -- post-processing the results, and generation of a nice > HTML page (this needs integrating on WineHQ as well). Not sure how you want to accomplish this, but integrating it into the site should not be hard, if the output is generated using the .template spec of the lostwages engine. If it need to be more dynamic than that, some PHP work will be involved. -- Jeremy Newman <jnewman(a)codeweavers.com> CodeWeavers, Inc.

Aug. 28, 2003

Re: Wine 0.9 progress

by Dimitrie O. Paun

On Thu, 28 Aug 2003, Ferenc Wagner wrote: > Basically, I cross-compiled the tests I could (all except > dsound), and run the attached script, which created the zip > file on the above page. A testing soul have to create a > directory, download a file, unzip it, run a .BAT file, and > mail a .TXT file. Cleanup is optional. I will write a > script which digests the resulting textfile and renders some > HTML. What do you think? Very nice. In fact, this is good enough to bridge us to when winetests will be ready. Esentially, winetests should just present a nice user interface and the extract/run/email/cleanup automatically. So yeah, now the focus should be in post-processing these results. Also, Jeremy can we setup a mailing lists/alias to where the results should be sent? This way we have a well-known entry point (e.g. wine-tests-results(a)winehq.org) and we've broken down the problem into simpler parts: -- creating the testing bundle (we'll need to integrate that in our build process, and regularly post fresh binary on our SF download site) -- the generation of the results is covered 80% by Feri's script, and work is underway to create a nice UI for it. -- post-processing the results, and generation of a nice HTML page (this needs integrating on WineHQ as well). -- Dimi.

Aug. 28, 2003

Re: make crosstest working again

by Francois Gouget

On Thu, 28 Aug 2003, Jakob Eriksson wrote: [...] > What is the issue with libuuid? I guess I have a relatively recent MinGW (3.2.1) so the following must be what Alexandre refers to: I get the following error: ~/wine/dlls/dsound/tests> i586-mingw32msvc-gcc dsound.cross.o propset.cross.o testlist.cross.o -o dsound_crosstest.exe -ldsound -luser32 -lkernel32 -lm dsound.cross.o(.text+0x15cd): In function `test_buffer': /home/fgouget/wine/wine/dlls/dsound/tests/dsound.c:380: undefined reference to `IID_IDirectSound3DBuffer' dsound.cross.o(.text+0x1612):/home/fgouget/wine/wine/dlls/dsound/tests/dsound.c:386: undefined reference to `IID_IDirectSoundBuffer' dsound.cross.o(.text+0x16d0):/home/fgouget/wine/wine/dlls/dsound/tests/dsound.c:393: undefined reference to `IID_IDirectSoundBuffer' dsound.cross.o(.text+0x23d5): In function `test_secondary': /home/fgouget/wine/wine/dlls/dsound/tests/dsound.c:523: undefined reference to `IID_IDirectSound3DListener' [... 41 lines in all ...] I can almost solve the problem if I add '-luuid -ldxguid' to the command. Then I only have: ~/wine/dlls/dsound/tests> i586-mingw32msvc-gcc dsound.cross.o propset.cross.o testlist.cross.o -o dsound_crosstest.exe -ldsound -luser32 -lkernel32 -lm -luuid -ldxguid propset.cross.o(.text+0xb77): In function `propset_private_tests': /home/fgouget/wine/wine/dlls/dsound/tests/propset.c:98: undefined reference to `CLSID_DirectSound8' propset.cross.o(.text+0xc81):/home/fgouget/wine/wine/dlls/dsound/tests/propset.c:118: undefined reference to `CLSID_DirectSoundCapture8' propset.cross.o(.text+0xd06):/home/fgouget/wine/wine/dlls/dsound/tests/propset.c:128: undefined reference to `CLSID_DirectSoundFullDuplex' propset.cross.o(.text+0xd91):/home/fgouget/wine/wine/dlls/dsound/tests/propset.c:138: undefined reference to `CLSID_DirectSoundPrivate' propset.cross.o(.text+0xe22):/home/fgouget/wine/wine/dlls/dsound/tests/propset.c:149: undefined reference to `DSPROPSETID_DirectSoundDevice' propset.cross.o(.text+0xebe):/home/fgouget/wine/wine/dlls/dsound/tests/propset.c:157: undefined reference to `DSPROPSETID_DirectSoundDevice' propset.cross.o(.text+0xf5a):/home/fgouget/wine/wine/dlls/dsound/tests/propset.c:165: undefined reference to `DSPROPSETID_DirectSoundDevice' propset.cross.o(.text+0x101e):/home/fgouget/wine/wine/dlls/dsound/tests/propset.c:181: undefined reference to `DSPROPSETID_DirectSoundDevice' The above looks like MinGW's dxguid library is missing the DirectX >= 8 GUIDs or somthing similar. In Wine most (all?) GUIDs are in wine_uuid which may also make things a bit harder in the Makefile when we try to fix this. The 'wine_' prefix is to avoid clashes with other Unix libraries. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ I haven't lost my mind, it's backed up on tape around here somewhere...

Aug. 28, 2003

Re: cleanup: include directives

by Steven Edwards

Jon Bright wrote: > It certainly looked to me like it did - are you sure your mailer didn't > interpret the mail as HTML, and the includes-in-angle-brackets as tags? Your right it was my client. Time to upgrade.

Aug. 28, 2003

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

by Dimitrie O. Paun

On 28 Aug 2003, Mike Hearn wrote: > Probably the best way to do it is to have a queue of transaction > structures, and each time you want to change a registry key (or rather > section/value pair) a new ConfigureTransaction is added to the tail of > the queue. The queue can either be processed instantly, or block until > OK/Cancel. That, or having a dirty flag would work as well. I think we should have a structure describing each value: struct config_param { const char *name; void *value; /* or we can have a union here */ int dirty; const char *flyby_help; HWND control; /* etc, etc. */ } On "Apply", we can simply walk the list and commit all things that are dirty. In general, I think it will be helpful going forward to be able to have such a thing in place so we can easily associtate metadata with each value. -- Dimi.

Aug. 28, 2003

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

by Mike Hearn

On Thu, 2003-08-28 at 21:02, Alexandre Julliard wrote: > It should definitely be possible to apply a subset of changes; we > don't want to rewrite the full config everytime a change is made. If I > toggle the "managed" flag for instance I expect that specific key to > be written to the registry, nothing else. Yes, it will complicate the > implementation a bit... OK. That's not how my current codebase works, but apply the patches anyway and I'll steer it onto a different course. Probably the best way to do it is to have a queue of transaction structures, and each time you want to change a registry key (or rather section/value pair) a new ConfigureTransaction is added to the tail of the queue. The queue can either be processed instantly, or block until OK/Cancel. Alternatively, you can also place marks in the queue, so you can do gnome2 style "Revert" buttons, ie all changes take effect immediately (or rather are written to the registry immediately), but you can basically undo any changes you made while the dialog is still open. That'd probably work quite well, though if we have an UI complex enough to need revert buttons we've probably gone wrong somewhere. Sound good?

Aug. 28, 2003

Re: patch for non x86 specific code in BuildSpec16File.

by Warren_Baird＠cimmetry.com

> Why do you want to do that? It will generate a lot of functions that > will never be used. Hi Alexandre, Dave forwarded your email to me, since I was the one who made that change in the first place... Perhaps the functions may never be used now --- but when I first started working with wine on solaris (Probably the march or apirl release of 2002) I got a bunch of undefined symbols until I removed the ifdef x86 here. I'm afraid that I can't recall whether the undefined symbols were in wine itself, or in our code. I've just undone the changes and wine did compile successfully, but I'm still waiting for our code to finish compiling... It could be tomorrow before it is done... It is quite possible that the problem that was causing the undefined symbols has been fixed in the last 1.5 years - I'll email if I do end up getting any undefined symbols. Until then you can disregard this patch. Warren

Aug. 28, 2003

Re: Wine 0.9 progress

by Ferenc Wagner

"Dimitrie O. Paun" <dimi(a)intelliware.ca> writes: > On Wed, 27 Aug 2003, Jakob Eriksson wrote: > >> I really was looking forward to write a testing >> application that runs all the tests. > > Yes, that would be very nice indeed. Such a test shell > should be something like the JUnit stuff. Here are few > things that I'd want in such an app: [...] Well, much less than what you want, but maybe something: http://afavant.elte.hu/~wferi/wine Basically, I cross-compiled the tests I could (all except dsound), and run the attached script, which created the zip file on the above page. A testing soul have to create a directory, download a file, unzip it, run a .BAT file, and mail a .TXT file. Cleanup is optional. I will write a script which digests the resulting textfile and renders some HTML. What do you think? Feri.

Aug. 28, 2003