June 2004 - Wine-devel - list.winehq.org

Re: Default to Windows 98 version, introduce new version mode 'auto' to use the DLL linkage heuristics
by Alexandre Julliard 18 Jun '04

18 Jun '04

Mike Hearn <mike(a)navi.cx> writes: > Mike Hearn <mike(a)navi.cx> > Default to Windows 98 version, introduce new version mode 'auto' > to use the DLL linkage heuristics. I'm not sure this is a good idea, it will require anybody who wants to use NT dlls to change the config or things will break, while they work fine today. I think it's better to keep the current way and improve the auto-detection if needed. -- Alexandre Julliard julliard(a)winehq.org

2 1

[test.winehq.org] missing tests
by Stefan Leichter 18 Jun '04

18 Jun '04

Hello, i noticed that not all dlls with unittests are listed inside the Main summary of test.winehq.org. Missing dlls are: iphlpapi, mapi32, msvcrtd, psapi, version Is there any reason for this? Bye Stefan

3 6

Re: FW: WM_NEXTDLGCTL changes the default button ID and does not rest ore default control identifier
by Alexandre Julliard 18 Jun '04

18 Jun '04

Krishna Murthy <Krishna.Murthy(a)guptaworldwide.com> writes: > + /** > + * if the next control is push button, then draw default push button > + * rectangle. > + * > + * if the next control is not a push button, then draw the push button > + * rectangle for the default control. > + * > + * Call SetDefButton to draw the default rectangle, but do not change the > + * default push button ID (idResult) - As Per MSDN > + */ > + if ( !(SendMessageW(hwndDest, WM_GETDLGCODE, 0, 0 ) & > + (DLGC_UNDEFPUSHBUTTON | DLGC_BUTTON)) ) > + hwndDest = GetDlgItem(hwnd, idSaveResult); > + DEFDLG_SetDefButton( hwnd, dlgInfo, GetDlgCtrlID(hwndDest) ); > + dlgInfo->idResult = idSaveResult; It seems you are doing redundant work here, since DEFDLG_SetDefButton will also send the same WM_GETDLGCODE. Wouldn't a simpler fix be to have DEFDLG_SetDefButton not set idResult unless it really changed the default button? -- Alexandre Julliard julliard(a)winehq.org

1 0

mmap of entire address space failed
by Gerald Pfeifer 18 Jun '04

18 Jun '04

On Tue, 15 Jun 2004, Alexandre Julliard wrote: > WHAT'S NEW with Wine-20040615: (see ChangeLog for details) > - Major winedbg rewrite using the dbghelp dll. > - New Wine preloader to reserve memory areas at startup. On FreeBSD 4.x, I'm now getting the following when trying to invoke Wine, even without any parameters: wine: failed to initialize: /swtest/wine/dlls/ntdll.dll.so: mmap of entire address space failed: Cannot allocate memory Gerald -- Gerald Pfeifer (Jerry) gerald(a)pfeifer.com http://www.pfeifer.com/gerald/

2 1

Memory allocation command
by Shachar Shemesh 17 Jun '04

17 Jun '04

Hi, The attached Windows program is compiled with support for 3GB user space. It is trying to allocate as much memory as it can, in 100MB chunks. On my unpatched Wine, it fails after allocating 10 chunks (i.e. - 1GB of data), which is consistent with the expected behavior as discussed with Alexandre on IRC. We should get it to succeed with allocating up to 2GB on regular compilation, and 3GB if it takes into consideration the memory reserving. Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/

1 0

Winedbg problem in 20040615
by Oliver 17 Jun '04

17 Jun '04

Hi, Just to confirm the current winedbg problem also with my system: Suse 9.1, Linux cassix 2.6.4-52-default #1 Wed Apr 7 02:08:30 UTC 2004 i686 i686 i386 GNU/Linux On Thursday 17 June 2004 16:48, Rein Klazes wrote: > > When I set breakpoints, I get a lot of messages like this: > > [...] > > fixme:dbghelp:elf_new_wine_thunks Duplicate in kernel32<elf>: > > module.0<40529348-00000004> module<40529348-00000000> > > fixme:dbghelp:elf_new_wine_thunks Duplicate in kernel32<elf>: > > iDateW.4<40509aba-0000000c> iDateW<40509aba-00000000> > > [...] > > This is discussed on the developer list, subject "Debugger spews > elf_new_wine_thunks fixmes". You are hitting bugs in the debugger, it > seems a good idea you send you questions to the developer list as it is > such a specialized item. Yes, a working winedbg would for the current CVS would be good. Especially setting the debugging channels again would be good. I have following problem there: Wine-dbg>set +file fixme:dbghelp:elf_new_wine_thunks Duplicate in imm32<elf>: name.0<4219a75c-00000012> name<4219a75c-00000000> [...] No symbols found for first_dll Can't get first_dll symbol Wine-dbg> Cheerio, Oliver

1 0

[ILLUSTRATOR10] not installable, need to merge 'winedefault.reg'
by Luca Capello 17 Jun '04

17 Jun '04

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, as reported in my previous mail, after the trick for DCOM95, 'Adobe Illustrator 10' is still not installable, cause this error: ===== luca(a)gismo:~$ wine win32_install/Adobe/Adobe.Illustrator.10/Adobe\ Illustrator\ 10/Setup.exe fixme:ole:RegisterTypeLib Registering non-oleautomation interface! fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects ERROR: You need to merge the 'winedefault.reg' file into your Wine registry by running: `regedit winedefault.reg' fixme:ole:_LocalServerThread CoMarshalInterface failed, 80070057! ERROR: You need to merge the 'winedefault.reg' file into your Wine registry by running: `regedit winedefault.reg' fixme:ole:_LocalServerThread CoMarshalInterface failed, 80070057! luca(a)gismo:~$ ===== But where I can find 'winedefault.reg' in the released 'wine-20040615'? ===== gismo:/home/luca# updatedb gismo:/home/luca# locate winedefault.reg /home/luca/cvs/cvs-commit/wine/Attic/winedefault.reg,v gismo:/home/luca# tar tzvf cvs/Wine-20040615.tar.gz | grep winedefault gismo:/home/luca# ===== Thx, bye, Gismo / Luca -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Debian - http://enigmail.mozdev.org iD8DBQFA0GgfVAp7Xm10JmkRAmIMAJ46H4w6ebQUd70GpSoKsmGC/d4riACfc637 Mdgnycwixh+1sZGbUzOA/WA= =25Pd -----END PGP SIGNATURE-----

3 3

Re: FW: WM_NEXTDLGCTL changes the default button ID and does not rest ore default control identifier
by Mike Hearn 17 Jun '04

17 Jun '04

On Thu, 2004-06-17 at 09:09 -0700, Krishna Murthy wrote: > I have submitted this patch last Friday. Today I got the latest update > from the CVS and found that the changes are not applied. > > Earlier I have found that the patches used to get updated overnight. > Please let me know if I am missing anything? OR the patch update > process takes some time? Probably it just needs thinking about, this sort of patch affects core parts of Wine and so often it takes Alexandre some time to decide if the patch is correct or not. Be patient, he is only human ;) Having said that, there are a few things you can do to make it more likely that patches will be applied quickly. 1) Use text mail rather than HTML mail. Alexandre applies patches by feeding the entire email to patch, so the less junk there is the more likely it is to just work. 2) You don't need to provide a long/short description, just a changelog entry is fine. If after a week or so the patch is still not applied, try resending it or asking why it was not applied on wine-devel. thanks -mike

2 1

RE: FW: WM_NEXTDLGCTL changes the default button ID and does not rest ore default control identifier
by Krishna Murthy 17 Jun '04

17 Jun '04

Thanks a lot. Krishna -----Original Message----- From: Mike Hearn [mailto:mike(a)navi.cx] Sent: Thursday, June 17, 2004 9:28 AM To: wine-devel(a)winehq.org Cc: Krishna Murthy Subject: Re: FW: WM_NEXTDLGCTL changes the default button ID and does not rest ore default control identifier On Thu, 2004-06-17 at 09:09 -0700, Krishna Murthy wrote: > I have submitted this patch last Friday. Today I got the latest update > from the CVS and found that the changes are not applied. > > Earlier I have found that the patches used to get updated overnight. > Please let me know if I am missing anything? OR the patch update > process takes some time? Probably it just needs thinking about, this sort of patch affects core parts of Wine and so often it takes Alexandre some time to decide if the patch is correct or not. Be patient, he is only human ;) Having said that, there are a few things you can do to make it more likely that patches will be applied quickly. 1) Use text mail rather than HTML mail. Alexandre applies patches by feeding the entire email to patch, so the less junk there is the more likely it is to just work. 2) You don't need to provide a long/short description, just a changelog entry is fine. If after a week or so the patch is still not applied, try resending it or asking why it was not applied on wine-devel. thanks -mike

1 0

How to test patches?
by Joel Konkle-Parker 17 Jun '04

17 Jun '04

I want to patch something in wrc/ (hopefully trivial), but I'm not sure how to test for any side effects. Is there a regression test suite or something you guys use to test your patches? Thanks. -- Joel Konkle-Parker Webmaster [Ballsome.com] E-mail [jjk3(a)msstate.edu]

2 1