December 2004 - Wine-Devel - list.winehq.org

Re: wine/ windows/win.c windows/painting.c server/ ...

by Dimitrie O. Paun

On Tue, Dec 07, 2004 at 11:31:53AM -0600, Alexandre Julliard wrote: > Log message: > Moved update region handling to the server. > > Patch: http://cvs.winehq.org/patch.py?id=14725 OK, here are the first impressions after testing this patch: 1. Good news: bug 1091 seems to have been fixed http://bugs.winehq.org/show_bug.cgi?id=1091 2. Bad news: it is *very* slow now. The repaint on wine List\ View.exe from the MS Control Spy is painful. Similarly, menus are slow, dialog boxes, etc. I have a fast machine (3GHz, 1GB RAM), and it takes 2-3 seconds to open the File Open dialog. Is this expected? Buttom line: painting looks great, somehow it seems a bit better then before (in terms of correctness, but I can't quite put my finger on it). If we can solve the speed issue, we have a winner. -- Dimi.

Dec. 7, 2004

Re: Feedback on user manual

by Scott Ritchie

On Wed, 2004-12-08 at 01:23 +0000, Mike Hearn wrote: > On Tue, 07 Dec 2004 17:02:01 -0800, Scott Ritchie wrote: > > Scott Ritchie, > > Self Proclaimed Wine Usability guy > > Good. We need one. I do my best but these days spend most of my time > writing app compat patches. Somebody who is specifically devoted to > usability can only be a good thing. > > Does it involve writing usability patches though? > Well, patches to the code not so much. My knowledge of wine internals isn't that hot, and frankly there's so much documentation and packaging work to do that we're probably better off if I just yell at people in IRC and email on code issues while I build packages and documentation. For example: please get winecfg working quickly :) I'm really excited about where AppDB is headed. With the new maintainer interface being finalized and the upcoming bug reporting documentation I'm making, nailing down exact problems should be a lot easier for you coding boys. One of the biggest developer complaints, that bug reports are little more than "my application doesn't work!" should soon dry up. I really do think we're on the verge of something truly groundbreaking. With things like the proposed desktop integration, the easier configuration programs, the possibility of winelib program packaging, and, dare I say it, a stable release version, wine may become one of the greatest and most important free software projects ever. This might sound like a lofty goal, but I believe it is very obtainable. So, I may as well say what I'm thinking: Within six months I believe it will be easier to install free windows software on Linux than in Windows. I believe I will be able to teach my mother how to have Ubuntu download and run a winelib compiled app in a few minutes. I believe that within a year wine will become so usable that The Economist will mention it in a story about how Linux is taking over Windows market share, even on the home desktop. And, finally, I believe that Microsoft will be worried that Wine can provide greater backward compatibility than Windows itself before they release Longhorn, so much so that they feel obligated to mention it in their SEC filings. Great work everyone, Scott Ritchie

Dec. 7, 2004

tools/wineinstall

by Christian Britz

Dear all, the script tools/wineinstall suggest to uninstall wine first if you update an existing installation. This makes senses but it is uncomfortable that the script doesn't offer the option to do that for the user. You always have to su before installing a new version Thx Christian

Dec. 7, 2004

Re: Jack Bug

by Christian Britz

Vincent Béron schrieb: >One of the winejack files was missing an #include statement, it should >be fixed in current CVS now. > > No. Maybe my server has not replicated yet. I'll inform you tommorow about success.

Dec. 7, 2004

Re: Searching for an existing Windows installation

by Bodo Thiesen

Christian Britz <cbritz(a)gmx.net> wrote: > because this step during the installation takes very long, I would > suggest to make it optional. wineinstall ~ line 35: DOWCHK=no # whether to autoconfigure existing-windows installation maybe you want to set DOWINE, too: DOWINE=yes # whether to autoconfigure no-windows installation Of course, a --help cmdline option wouldn't be bad, and a way to set this values using cmdline options wouldn't be bad, too. Regards, Bodo

Dec. 7, 2004

Re: Feedback on user manual

by Mike Hearn

On Tue, 07 Dec 2004 17:02:01 -0800, Scott Ritchie wrote: > Scott Ritchie, > Self Proclaimed Wine Usability guy Good. We need one. I do my best but these days spend most of my time writing app compat patches. Somebody who is specifically devoted to usability can only be a good thing. Does it involve writing usability patches though?

Dec. 7, 2004

Re: Jack Bug

by Vincent Béron

Le mar 07/12/2004 à 17:38, Christian Britz a écrit : > Christian Britz wwrote accidentially to himself: > > > >>>>Vanilla Kernel 2.6.9, Alsa support, libjack0.80.0-dev not installed what > >>>> > >> > >> > >> > >>Sorry, that was was wrong, the dev package IS installed! > >> > > > > > When I remove this package everything compiles fine! > > So i guess jack support is broken. One of the winejack files was missing an #include statement, it should be fixed in current CVS now. Vincent

Dec. 7, 2004

Searching for an existing Windows installation

by Christian Britz

Dear all, because this step during the installation takes very long, I would suggest to make it optional. Mit freundlichen Grüßen Christian

Dec. 7, 2004

IMM_Register and Flight Simulator 98

by Robert Reif

Just tried to install Flight Simulator 98 with latest CVS and got this: [wine(a)dell cdrom1]$ wine setup.exe wine: Unhandled exception (thread 0009), starting debugger... WineDbg starting on pid 0x8 Unhandled exception: page fault on read access to 0x000004d0 in 32-bit code (0x40e42e67). In 32 bit mode. Register dump: CS:0023 SS:002b DS:002b ES:002b FS:0033 GS:004f EIP:40e42e67 ESP:4081f394 EBP:4081f3bc EFLAGS:00010212( - 00 - RIA1) EAX:00000000 EBX:40f0b1e4 ECX:40502a9f EDX:00000000 ESI:40e15a98 EDI:40322f50 Stack dump: 0x4081f394: 4081f3bc 409816e0 000000be 00000000 0x4081f3a4: 00000000 00000000 40e42e5b 40e11220 0x4081f3b4: 40e15a98 40322f50 4081f3e0 40dd85e3 0x4081f3c4: 00000000 000000b6 00000000 00000000 0x4081f3d4: 40997614 40322c28 40322e10 4081f67c 0x4081f3e4: 4095a025 0000004c 40322e28 4081f410 Backtrace: =>1 0x40e42e67 ?? +0x17 in libx11.so.6 (0x4081f3bc) 2 0x40dd85e3 X11DRV_CreateDC+0x87(hdc=0x4c, pdev=0x40322e28, driver=0x4081f410, device=0x0, output=0x0, initData=0x0) [/home/wine/wine/dlls/x11drv/init.c:153] in x11drv (0x4081f3e0) 3 0x4095a025 CreateDCW+0xed(driver=0x408d2f50, device=0x0, output=0x0, initData=0x0) [/home/wine/wine/dlls/gdi/dc.c:609] in gdi32 (0x4081f67c) 4 0x40861503 CURSORICON_CreateFromResource+0x65f(hModule=0x0, hObj=0x0, bits=0x408c5740, cbSize=0x134, bIcon=0x0, dwVersion=0x30000, width=0x20, height=0x20, loadflags=0x8040) [/home/wine/wine/dlls/user/../../windows/cursoricon.c:711] in user32 (0x4081f70c) 5 0x408616eb CURSORICON_Load+0x12f(hInstance=0x0, name=0x7f00, width=0x0, height=0x0, colors=0x1, fCursor=0x1, loadflags=0x8040) [/home/wine/wine/dlls/user/../../windows/cursoricon.c:971] in user32 (0x4081f75c) 6 0x4086390f LoadImageW+0x8b(hinst=0x0, name=0x7f00, type=0x2, desiredx=0x0, desiredy=0x0, loadflags=0x8040) [/home/wine/wine/dlls/user/../../windows/cursoricon.c:2272] in user32 (0x4081f790) 7 0x40862a5e LoadCursorW+0x26(hInstance=0x0, name=0x7f00) [/home/wine/wine/dlls/user/../../windows/cursoricon.c:1715] in user32 (0x4081f7b4) 8 0x41747762 IMM_Register+0x5a [/home/wine/wine/dlls/imm32/imm.c:107] in imm32 (0x4081f800) 9 0x417478d8 DllMain+0x78(hInstDLL=0x41740000, fdwReason=0x1, lpReserved=0x0) [/home/wine/wine/dlls/imm32/imm.c:146] in imm32 (0x4081f814) 10 0x41746f88 __wine_dll_main+0x60 in imm32 (0x4081f844) 11 0x401a2cee call_dll_entry_point+0x12 in ntdll (0x4081f85c) 12 0x401a3d07 MODULE_InitDLL+0xe3(wm=0x40322b80, reason=0x1, lpReserved=0x0) [/home/wine/wine/dlls/ntdll/loader.c:741] in ntdll (0x4081f8cc) 13 0x401a3ee4 process_attach+0xf8(wm=0x40322b80, lpReserved=0x0) [/home/wine/wine/dlls/ntdll/loader.c:814] in ntdll (0x4081f8f0) 14 0x401a56e0 LdrLoadDll+0x84(path_name=0x40322ab8, flags=0x0, libname=0x4081f954, hModule=0x4081f934) [/home/wine/wine/dlls/ntdll/loader.c:1565] in ntdll (0x4081f914) 15 0x40466d73 load_library+0x4b(libname=0x4081f954, flags=0x0) [/home/wine/wine/dlls/kernel/module.c:671] in kernel32 (0x4081f944) 16 0x40466e3a LoadLibraryExW+0x2e(libnameW=0x40014c00, hfile=0x0, flags=0x0) [/home/wine/wine/dlls/kernel/module.c:726] in kernel32 (0x4081f964) 17 0x40466dfe LoadLibraryExA+0x2e(libname=0x40e0bfc4, hfile=0x0, flags=0x0) [/home/wine/wine/dlls/kernel/module.c:707] in kernel32 (0x4081f97c) 18 0x40466e70 LoadLibraryA+0x1c(libname=0x40e0bfc4) [/home/wine/wine/dlls/kernel/module.c:746] in kernel32 (0x4081f994) 19 0x40df2064 LoadImmDll+0x1c [xim.c:78] in x11drv (0x4081f9a4) 20 0x40df29bb X11DRV_SetupXIM+0x127(display=0x7801c0b8, input_style=0x40e15978) [/home/wine/wine/dlls/x11drv/xim.c:440] in x11drv (0x4081f9d4) 21 0x40deb656 x11drv_init_thread_data+0x11a [/home/wine/wine/dlls/x11drv/x11drv_main.c:502] in x11drv (0x4081f9f0) 22 0x40dc41d1 X11DRV_create_desktop+0x289(desktop_vi=0x0, geometry=0x78020580) [/home/wine/wine/dlls/x11drv/desktop.c:251] in x11drv (0x4081fa78) 23 0x40deb3ac process_attach+0x150 [/home/wine/wine/dlls/x11drv/x11drv_main.c:395] in x11drv (0x4081fa9c) 24 0x40deb761 DllMain+0x39(hinst=0x40db0000, reason=0x1, reserved=0x0) [/home/wine/wine/dlls/x11drv/x11drv_main.c:524] in x11drv (0x4081faa8) 25 0x40dbb6d4 __wine_dll_main+0x60 in x11drv (0x4081fad8) 26 0x401a2cee call_dll_entry_point+0x12 in ntdll (0x4081faf0) 27 0x401a3d07 MODULE_InitDLL+0xe3(wm=0x40322978, reason=0x1, lpReserved=0x0) [/home/wine/wine/dlls/ntdll/loader.c:741] in ntdll (0x4081fb60) 28 0x401a3ee4 process_attach+0xf8(wm=0x40322978, lpReserved=0x0) [/home/wine/wine/dlls/ntdll/loader.c:814] in ntdll (0x4081fb84) 29 0x401a56e0 LdrLoadDll+0x84(path_name=0x403228a8, flags=0x0, libname=0x4081fbe8, hModule=0x4081fbc8) [/home/wine/wine/dlls/ntdll/loader.c:1565] in ntdll (0x4081fba8) 30 0x40466d73 load_library+0x4b(libname=0x4081fbe8, flags=0x0) [/home/wine/wine/dlls/kernel/module.c:671] in kernel32 (0x4081fbd8) 31 0x40466e3a LoadLibraryExW+0x2e(libnameW=0x40014c00, hfile=0x0, flags=0x0) [/home/wine/wine/dlls/kernel/module.c:726] in kernel32 (0x4081fbf8) 32 0x40466dfe LoadLibraryExA+0x2e(libname=0x4081fc44, hfile=0x0, flags=0x0) [/home/wine/wine/dlls/kernel/module.c:707] in kernel32 (0x4081fc10) 33 0x40466e70 LoadLibraryA+0x1c(libname=0x4081fc44) [/home/wine/wine/dlls/kernel/module.c:746] in kernel32 (0x4081fc28) 34 0x408c2c42 load_driver+0x7a [user_main.c:75] in user32 (0x4081fd60) 35 0x408c321f process_attach+0x47 [/home/wine/wine/dlls/user/user_main.c:180] in user32 (0x4081fd70) 36 0x408c33cc DllMain+0x50(inst=0x40840000, reason=0x1, reserved=0x1) [/home/wine/wine/dlls/user/user_main.c:260] in user32 (0x4081fd80) 37 0x40851218 __wine_dll_main+0x60 in user32 (0x4081fdb0) 38 0x401a2cee call_dll_entry_point+0x12 in ntdll (0x4081fdc8) 39 0x401a3d07 MODULE_InitDLL+0xe3(wm=0x402f0908, reason=0x1, lpReserved=0x1) [/home/wine/wine/dlls/ntdll/loader.c:741] in ntdll (0x4081fe38) 40 0x401a3ee4 process_attach+0xf8(wm=0x402f0908, lpReserved=0x1) [/home/wine/wine/dlls/ntdll/loader.c:814] in ntdll (0x4081fe5c) 41 0x401a3f13 process_attach+0x127(wm=0x402f07c8, lpReserved=0x1) [/home/wine/wine/dlls/ntdll/loader.c:806] in ntdll (0x4081fe7c) 42 0x401a5fe6 LdrInitializeThunk+0x1f2(main_file=0x0, unknown2=0x0, unknown3=0x0, unknown4=0x0) [/home/wine/wine/dlls/ntdll/loader.c:1902] in ntdll (0x4081ff20) 43 0x40471433 start_process+0x9b(arg=0x0) [/home/wine/wine/dlls/kernel/process.c:1036] in kernel32 (0x4081fff4) 44 0x400298f5 wine_pthread_abort_thread+0x29(status=0x0) [port.c:85] in libwine.so.1 (0x00000000) 0x40e42e67 ?? +0x17 in libx11.so.6: movl 0x4d0(%edx),%eax Wine-dbg>

Dec. 7, 2004

Re: Feedback on user manual

by Scott Ritchie

Please don't use the official Debian packages, they are rather out of date. Instead, please use the winehq.org .deb files (I'll upload instructions on how to get them by tomorrow), or compile from CVS. The documentation is also currently undergoing a rewrite - you can see its status as of the latest release on the winehq.org web page. Currently, only the introduction of the user guide is in its updated state - I'm working on patching up the Getting Wine chapter as well as some other stuff like the bug reporting guide. Thank you for your input though, Scott Ritchie, Self Proclaimed Wine Usability guy On Tue, 2004-12-07 at 13:06 -0800, Ross Boylan wrote: > The manual lamented the lack of feedback, so I thought I'd give you > some. > 1.1.1 says "It tries to target both the new Wine user, by offering a > step by step approach, and the experienced Wine user, by offering the > reference material mentioned above." > > Ordinarily, I would expect the novice stuff, followed by reference > material. But, judging from the table of contents, this isn't what > you've done. It would be good to say how the stuff is arranged. > > Assuming the novice and expert stuff is interspersed, it might be better > to separate them. Yes, I realize that's probably a lot of work. That's > why this is only a though :) > > You might also want to put a date and version number on the > documentation; at least on Debian, looking at the html, I don't see it. > I'm using wine-doc 0.0.20040716-1.3. > > Thanks for your work on wine.

Dec. 7, 2004

Problems using WineDbg

by Bodo Thiesen

Ok, I'm trying to use winedbg to check, why a game doesn't work, but: $ /cd_autorun Zeus Using /cdimages/mnt/Zeus/AUTORUN.INF as Autorun.Inf Using Z:\autorun.exe as Autorun.Exe Setting WINEPREFIX to /.wine-Zeus Starting Z:\autorun.exe using cmdline /bin/wine Z:\autorun.exe Xlib: extension "GLX" missing on display "localhost:0.0". fixme:ddraw:Main_DirectDraw_SetCooperativeLevel (0x40359328)->(0002002e,00000013) fixme:ddraw:Main_DirectDraw_SetCooperativeLevel (0x40359328)->(0002002e,00000008) fixme:ddraw:Main_DirectDraw_SetCooperativeLevel (0x40359328)->(0002002e,00000013) fixme:ddraw:DIB_DirectDrawSurface_Blt dwFlags DDBLT_WAIT and/or DDBLT_ASYNC: can't handle right now. wine: Unhandled exception (thread 000f), starting debugger... WineDbg starting on pid 0xe Unhandled exception: page fault on read access to 0x5a202d28 in 32-bit code (0x21113913). In 32 bit mode. Register dump: CS:0023 SS:002b DS:002b ES:002b FS:1007 GS:007f EIP:21113913 ESP:4067f8b8 EBP:4067fcdc EFLAGS:00010206( - 00 - RIP1) EAX:00000000 EBX:41a54f80 ECX:5a202d28 EDX:00737565 ESI:403ae428 EDI:41a552e8 Stack dump: 0x4067f8b8: 41a55228 21103fa6 403ae428 41a55228 0x4067f8c8: 10029005 403ae428 0000ac44 00000000 0x4067f8d8: 100086c8 41a55228 0000ac44 00000010 0x4067f8e8: 00000002 08000000 41a54f80 4067fe0c 0x4067f8f8: 00000000 4051d10c 00000280 000001e0 0x4067f908: 00000e85 00000000 00000000 0000001e 0200: sel=1007 base=40016000 limit=00001f97 32-bit rw- Backtrace: =>1 0x21113913 in mss32 (+0x13913) (0x4067fcdc) 2 0x0042300b in zeus (+0x2300b) (0x4067fdbc) 3 0x00603f1f in zeus (+0x203f1f) (0x4067fe94) 4 0x0060f8ae EntryPoint+0xce in zeus (0x4067ff20) 5 0x40481a65 start_process+0x135(arg=0x0) [/wine/dlls/kernel/process.c:1046] in kernel32 (0x4067fff4) 6 0x4001d361 wine_pthread_abort_thread+0x31(status=0x0) [port.c:85] in libwine.so.1 (0x00000000) 0x21113913: cmpl $1,0x0(%ecx) Wine-dbg>info registers{PRESSED ENTER} Register dump: CS:0023 SS:002b DS:002b ES:002b FS:1007 GS:007f EIP:21113913 ESP:4067f8b8 EBP:4067fcdc EFLAGS:00010206( - 00 - RIP1) EAX:00000000 EBX:41a54f80 ECX:5a202d28 EDX:00737565 ESI:403ae428 EDI:41a552e8 Wine-dbg>bt{PRESSED ENTER} Backtrace: =>1 0x21113913 in mss32 (+0x13913) (0x4067fcdc) 2 0x0042300b in zeus (+0x2300b) (0x4067fdbc) 3 0x00603f1f in zeus (+0x203f1f) (0x4067fe94) 4 0x0060f8ae EntryPoint+0xce in zeus (0x4067ff20) 5 0x40481a65 start_process+0x135(arg=0x0) [/wine/dlls/kernel/process.c:1046] in kernel32 (0x4067fff4) 6 0x4001d361 wine_pthread_abort_thread+0x31(status=0x0) [port.c:85] in libwine.so.1 (0x00000000) Wine-dbg>${PRESSED ENTER} )Syntax Error ( Wine-dbg>WineDbg terminated on pid 0xe {PRESSED ENTER} $ So, in the very first seconds, I still can interact with winedbg, but then it suddenly disappears, and I get back my shell. No chance to investigate the problem using winedbg this way. There are some other strage missbehaviors, like printing 10000 times 'Wine-dbg>' before being killed using kill -kill <wine-pids>, or even not printing the register dump + back trace in the first place like shown above (same application, startup phase). So not even every time I try winedbg, everything happens identical. I'm using wine-cvs just checked out and rebuild using command line: $ cvs up && ./configure -C --prefix=/ && make depend && make && make install Regards, Bodo

Dec. 7, 2004

Jack Bug

by Christian Britz

Christian Britz wwrote accidentially to himself: >>>>Vanilla Kernel 2.6.9, Alsa support, libjack0.80.0-dev not installed what >>>> >> >> >> >>Sorry, that was was wrong, the dev package IS installed! >> > > When I remove this package everything compiles fine! So i guess jack support is broken. Regards Christian

Dec. 7, 2004

Wine CVS still broken

by Florian Goth

I deleted my wine - folder and did a full cvs checkout today(23:00 CET ) But there's still a problem in winejack: The previously reported errors seem to be away gcc -c -I. -I. -I../../../include -I../../../include -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -O2 -march=athlon-xp -m32 -mmmx -m3dnow -msse -ftracer -funroll-loops -fpeel-loops -funswitch-loops -fweb -funit-at-a-time -o winejack.drv.dbg.o winejack.drv.dbg.c ../../../tools/winegcc/winegcc -B../../../tools/winebuild -shared ./winejack.drv.spec audio.o jack.o winejack.drv.dbg.o -o winejack.drv.so -L../../../dlls -lwinmm -luser32 -lkernel32 -L../../../libs/wine -lwine -ldxguid -luuid -L../../../libs/port -lwine_port audio.o(.text+0x22fe): In function `JACK_WaveInit': /home/sifff/wine/dlls/winmm/winejack/audio.c:935: undefined reference to `strcpyW' audio.o(.text+0x23de):/home/sifff/wine/dlls/winmm/winejack/audio.c:969: undefined reference to `strcpyW' collect2: ld gab 1 als Ende-Status zurück winegcc: gcc failed. make[2]: *** [winejack.drv.so] Fehler 2 make[2]: Leaving directory `/home/sifff/wine/dlls/winmm/winejack' make[1]: *** [winmm/winejack] Fehler 2 make[1]: Leaving directory `/home/sifff/wine/dlls' make: *** [dlls] Fehler 2

Dec. 7, 2004

Re: Bug Confirmation (was Re: current CVS broken.)

by Christian Britz

Christian Britz schrieb: >Vanilla Kernel 2.6.9, Alsa support, libjack0.80.0-dev not installed what > Sorry, that was was wrong, the dev package IS installed!

Dec. 7, 2004

Bug Confirmation (was Re: current CVS broken.)

by Christian Britz

Dear all, Ivan Leo Puoti wrote: >I believe this patch >http://www.winehq.com/hypermail/wine-cvs/2004/12/0081.html >is causing this compile error on my system. > >make[2]: Entering directory `/path/to/wine/source/dlls/winmm/winejack' > > [...] I can confirm this, same problem here. As I am not currently a developer, it would be nice if some competent person could comment on this. Especially I would like to know if this could be related to our configuration (for me Debian GNU/Linux Sarge, Vanilla Kernel 2.6.9, Alsa support, libjack0.80.0-dev not installed what may cause the problem). Thx for assistance, Christian

Dec. 7, 2004

Re: Includes [1] ntdll

by Andreas Mohr

Hi, On Tue, Dec 07, 2004 at 01:20:57PM -0700, tony_lambregts(a)telusplanet.net wrote: > Considering that it takes 6-8 hours to compile on my poor old machine > I would appreciate anything that would speed up the process. I dread > having to do a ./configure. I know you guy's with your multi GHz > machines might say so what, but it would increase your productivity too. And what about gcc 3.4.x precompiled headers? That should also be a worthwhile target, considering that (as I mentioned before) I managed to hit a tenfold compile performance with my program. > Also before you laugh at my machine. One of the primary reasons for me to > use this machine is that there lots of these older machines out there > (peticularly in the developing world) and I think wine should be useable > on anything that it can. Indeed! I loathe bloatware! Anything that can be done to reduce wait times and memory footprint is a very good thing. Andreas Mohr

Dec. 7, 2004

Feedback on user manual

by Ross Boylan

The manual lamented the lack of feedback, so I thought I'd give you some. 1.1.1 says "It tries to target both the new Wine user, by offering a step by step approach, and the experienced Wine user, by offering the reference material mentioned above." Ordinarily, I would expect the novice stuff, followed by reference material. But, judging from the table of contents, this isn't what you've done. It would be good to say how the stuff is arranged. Assuming the novice and expert stuff is interspersed, it might be better to separate them. Yes, I realize that's probably a lot of work. That's why this is only a though :) You might also want to put a date and version number on the documentation; at least on Debian, looking at the html, I don't see it. I'm using wine-doc 0.0.20040716-1.3. Thanks for your work on wine. -- Ross Boylan wk: (415) 502-4031 530 Parnassus Avenue (Library) rm 115-4 ross(a)biostat.ucsf.edu Dept of Epidemiology and Biostatistics fax: (415) 476-9856 University of California, San Francisco San Francisco, CA 94143-0840 hm: (415) 550-1062

Dec. 7, 2004

Re: Includes [1] ntdll

by Dimitrie O. Paun

On Tue, Dec 07, 2004 at 01:20:57PM -0700, tony_lambregts(a)telusplanet.net wrote: > Considering that it takes 6-8 hours to compile on my poor old machine Wow! I thought 1h on my old box was excessive. What kind of machine is that? -- Dimi.

Dec. 7, 2004

Re: Includes [1] ntdll

by tony_lambregts＠telusplanet.net

Jon Griffiths wrote: [Snip] > > > Yes, its a little crufty as-is. My reasoning is that anything that > reduces my compile times after updates is good, and my laptop takes > quite a while to rebuild Wine, Minimising dependencies helps that. > > On a related note, would anyone object to a patch that auto-split > config.h into multiple files during the build process, and changing > makedep to generate dependencies only on the generated config-value > file? > > This would be a big win whenever config.h changes. Currently when > config.h changes, 980 files are rebuilt. Using a smarter method would > only rebuild the files that depend on the HAVE_ option that was > changed (which is bound to be a significantly smaller number). > > The Linux kernel process does this already, check out > /usr/src/linux/Documentation/smart-config.txt for details. > > Thoughts? > Considering that it takes 6-8 hours to compile on my poor old machine I would appreciate anything that would speed up the process. I dread having to do a ./configure. I know you guy's with your multi GHz machines might say so what, but it would increase your productivity too. Also before you laugh at my machine. One of the primary reasons for me to use this machine is that there lots of these older machines out there (peticularly in the developing world) and I think wine should be useable on anything that it can. -- Tony lambregts and around and around

Dec. 7, 2004

Re: wine/ windows/win.c windows/painting.c server/ ...

by Mike Hearn

On Tue, 07 Dec 2004 14:52:03 -0500, Dimitrie O. Paun wrote: > On Tue, Dec 07, 2004 at 11:31:53AM -0600, Alexandre Julliard wrote: > > Log message: > > Moved update region handling to the server. > > > > Patch: http://cvs.winehq.org/patch.py?id=14725 > > Cool stuff! Way to go Alexandre, this is really, really good news! Yep yep yep, good to see. Soon we can start nailing all those bugs blocked on the WM rewrite. Hey, maybe I can resubmit my LockWindowUpdate patch soon :) Flip side is there are still a few regressions from the previous WM work that I haven't got around to investigating (or reporting, for that matter ..)

Dec. 7, 2004

Re: wine/ windows/win.c windows/painting.c server/ ...

by Dimitrie O. Paun

On Tue, Dec 07, 2004 at 11:31:53AM -0600, Alexandre Julliard wrote: > Log message: > Moved update region handling to the server. > > Patch: http://cvs.winehq.org/patch.py?id=14725 Cool stuff! Way to go Alexandre, this is really, really good news! -- Dimi.

Dec. 7, 2004

Re: Includes [1] ntdll

by Robert Shearman

Jon Griffiths wrote: >Hi, > >--- Andreas Mohr <andi(a)rhlx01.fht-esslingen.de> wrote: > > >>Note that some removed include files might be needed for different >>systems, >>so some breakage might/may/will follow this patch. >> >> > >I deliberately made my script remove only Wines own headers for this >reason. It will not remove system header files. I also manually >checked that nothing within an #ifdef block was deleted. So this >shouldn't cause any problems for other *nices. > > Do the patches take into account that a header might only be included to check that an exported function matches the declaration in the header file? Rob

Dec. 7, 2004

Re: Genrate stdole32.tlb file, and install generated files

by Mike Hearn

On Tue, 07 Dec 2004 17:17:12 +0100, Alexandre Julliard wrote: > Not really, it should probably be created by winebuild like other > builtin dlls, or else directly in PE format by widl. Either way it > won't be done from a Winelib app (but don't let this discourage you > from finishing the UpdateResource support ;-) Hmm, so the approach with a custom app generating stdole32.tlb is not OK? As far as I'm aware this is what Microsoft do, I thought there were constructs in this file that midl/widl could not generate.

Dec. 7, 2004

Re: Help with some strange debugging.

by Mike Hearn

On Tue, 07 Dec 2004 01:02:27 +0000, Oliver Stieber wrote: > I've also got a little patch for oleaut/varient.c to > allow number-string comparisons. There are a couple of > undocumented assumptions I've made,like what to return > for an empty of if the string isn't a number, and the > only thing I've been able to test with is 1 vb > application as I don't have windows, should I post it > to this list or to patch? Send it to wine-patches, and check that the test suite still passes if you change any variant code (run make test). thanks -mike

Dec. 7, 2004

Re: Includes [4] shlwapi

by Jon Griffiths

Hi Juan, > winnls.h declares WideCharToMultiByte, and we just saw a > compilation error > on some systems because it was missing [1]. winnls.h is included already by wine/unicode.h in url.c, so its not needed again there. The script I wrote basically comments out the includes one at a time, and restores any that caused a compile failure when missing. The worst that could happen is that a new warning could be generated, but I rebuilt all the files, check the build logs and believe I got them all. Cheers, Jon P.S. I will be trying your patch as soon as I can clean up my tree a bit :-) ===== "Don't wait for the seas to part, or messiahs to come; Don't you sit around and waste this chance..." - Live jon_p_griffiths(a)yahoo.com __________________________________ Do you Yahoo!? Yahoo! Mail - Find what you need with new enhanced search. http://info.mail.yahoo.com/mail_250

Dec. 7, 2004

Re: Includes [4] shlwapi

by Juan Lang

Jon, are you sure about removing the winnls.h includes? This patch looks suspect: > diff -ur wine/dlls/shlwapi/url.c wine-develop/dlls/shlwapi/url.c > --- wine/dlls/shlwapi/url.c 2004-12-03 23:27:08.000000000 -0500 > +++ wine-develop/dlls/shlwapi/url.c 2004-12-06 15:42:34.000000000 -0500 > @@ -25,8 +25,6 @@ > #include <stdlib.h> > #include "windef.h" > #include "winbase.h" > -#include "winnls.h" > -#include "winerror.h" > #include "wine/unicode.h" > #include "wininet.h" > #include "winreg.h" > @@ -1416,7 +1414,7 @@ > * return the same digests for the same URL. > */ > WideCharToMultiByte(0, 0, pszUrl, -1, szUrl, MAX_PATH, 0, 0); > - HashData((PBYTE)szUrl, (int)strlen(szUrl), lpDest, nDestLen); > + HashData((const BYTE*)szUrl, (int)strlen(szUrl), lpDest, nDestLen); > return S_OK; > } winnls.h declares WideCharToMultiByte, and we just saw a compilation error on some systems because it was missing [1]. I haven't checked others, but this caught my eye. [1] http://www.winehq.org/hypermail/wine-cvs/2004/12/0091.html --Juan __________________________________ Do you Yahoo!? Yahoo! Mail - Find what you need with new enhanced search. http://info.mail.yahoo.com/mail_250

Dec. 7, 2004

Fwd:[Fwd: [AppDB] Status Report]

by Ivan Leo Puoti

Can someone working on appdb fix this? Ivan. ____________________________________________________________ Libero ADSL: 3 mesi gratis e navighi a 1.2 Mega, senza costi di attivazione. Abbonati subito su http://www.libero.it

Dec. 7, 2004

Re: Includes [1] ntdll

by Jon Griffiths

Hi, --- Andreas Mohr <andi(a)rhlx01.fht-esslingen.de> wrote: > Note that some removed include files might be needed for different > systems, > so some breakage might/may/will follow this patch. I deliberately made my script remove only Wines own headers for this reason. It will not remove system header files. I also manually checked that nothing within an #ifdef block was deleted. So this shouldn't cause any problems for other *nices. If there is an issue it will be with mingw or VC++. But that would point out an incompatability in our headers with theirs, and that would be a good thing, IMHO. > (Gerald Pfeifer will *love* your "nice" work, I'm sure ;-) I'm happy if Gerald wants to try the patches for beakage before they are committed... > But I'd still vote strongly for including it, since it will remove > lots of cruft. Yes, its a little crufty as-is. My reasoning is that anything that reduces my compile times after updates is good, and my laptop takes quite a while to rebuild Wine, Minimising dependencies helps that. On a related note, would anyone object to a patch that auto-split config.h into multiple files during the build process, and changing makedep to generate dependencies only on the generated config-value file? This would be a big win whenever config.h changes. Currently when config.h changes, 980 files are rebuilt. Using a smarter method would only rebuild the files that depend on the HAVE_ option that was changed (which is bound to be a significantly smaller number). The Linux kernel process does this already, check out /usr/src/linux/Documentation/smart-config.txt for details. Thoughts? Cheers, Jon ===== "Don't wait for the seas to part, or messiahs to come; Don't you sit around and waste this chance..." - Live jon_p_griffiths(a)yahoo.com __________________________________ Do you Yahoo!? The all-new My Yahoo! - What will yours do? http://my.yahoo.com

Dec. 7, 2004

Re: Genrate stdole32.tlb file, and install generated files

by Alexandre Julliard

Vincent Béron <vberon(a)mecano.gme.usherb.ca> writes: > I guess the easiest way (if we keep a winelib app) is to use > {Begin,End,}UpdateResource{A,W} from kernel32.dll? Not really, it should probably be created by winebuild like other builtin dlls, or else directly in PE format by widl. Either way it won't be done from a Winelib app (but don't let this discourage you from finishing the UpdateResource support ;-) -- Alexandre Julliard julliard(a)winehq.org

Dec. 7, 2004

Re: Includes [1] ntdll

by Andreas Mohr

Hi, On Tue, Dec 07, 2004 at 06:15:39AM -0800, Jon Griffiths wrote: > Hi, > > On the suspicion that my hacking on header files was causing too many > files to be rebuilt, I whipped up a quick perl script to identify > unneeded header files. This series of patches is the result. Nice stuff, but... where is it? The most important part, I mean: the perl script ;-) Note that some removed include files might be needed for different systems, so some breakage might/may/will follow this patch. (Gerald Pfeifer will *love* your "nice" work, I'm sure ;-) But I'd still vote strongly for including it, since it will remove lots of cruft. Thanks, Andreas Mohr

Dec. 7, 2004

Re: IME fixes

by Aric Stewart

You have a few places where variable declaration has moved from the top of the function to under your block. That should be fixed. It is hard to read through the whitespace changes for me. I though general convention was that you did not change whitespace (i seems to remember a small war over that) other than that things look ok. Have you tested this by setting your locale to ja_JP or zh_CN or ko_KR to make sure the fixme come back and such? thanks -aric Ivan Leo Puoti wrote: > We have 2 space, 4 space and 5 space indentation in ime.c, so fix that. > Also behave like windows if we're on a locale that doesn't support, by returning 0 > after setting last error to 120. > > Ivan.

Dec. 7, 2004

Re: No more winrash?

by Dmitry Timoshkov

"Jakob Eriksson" <jakov(a)vmlinux.org> wrote: > Well, line 183 in dlls/gdi/tests/metafile.c detects rather nicely whether > we are running in an interactive desktop or not. > > I could copy that logic to winetest.exe > > metafile.c : 183 > ok(emr_processed, "EnumEnhMetaFile couldn't find EMR_EXTTEXTOUTA or > EMR_EXTTEXTOUTW record\n"); > > ( > http://test.winehq.org/data/200412021000/2000_JakobErikssonBW/gdi32:metafil… > ) A better and much simpler test is: if (!(GetWindowLongA(GetDesktopWindow(), GWL_STYLE) & WS_VISBLE)) trace("running on a not visible desktop\n"); -- Dmitry.

Dec. 7, 2004

Re: Shell about box

by Dmitry Timoshkov

"Ge van Geldorp" <gvg(a)reactos.com> wrote: > Changelog: > Klemens Friedl <frik85(a)hotmail.com> > - Design Shell About dialog more Windows-like The patch will not apply since it's utf-8 encoded. -- Dmitry.

Dec. 7, 2004

Re: No more winrash?

by Chris Morgan

If the implementation of automated testing is broken why not fix it or work around the issues rather than abandon the whole idea? Isn't it useful to have all non-interactive tests run automatically on dozens of machines? If it isn't useful then I agree, we should stop the automated testing. Chris On Tuesday 07 December 2004 5:25 am, Ferenc Wagner wrote: > Jakob Eriksson <jakov(a)vmlinux.org> writes: > > Do you agree, should we stop using winrash? > > > > "Dmitry Timoshkov" <dmitry(a)baikal.ru> wrote: > >> "Jakob Eriksson" <jakov(a)vmlinux.org> wrote: > >>> Well, I tried now marking the service as interactive, > >>> but that didn't make any difference. > >>> > >>> So, what follows, deprecate Winrash? > >> > >> If it really breaks the tests then definitely yes. > > I think it does provide much useful information which would > be largely lost if we resorted to manual testing. What's > more, winetest is not really up to that, as it doesn't ask > for a tag but relies on a command line option which people > would tend to forget. What I propose: make winetest detect > whether it's running on an interactive desktop or not, and > include this info in the header just like bRunningUnderWine. > Meanwhile add the tag dialog to winetest and separate or > mark the different reports on the webpage for easier > reference. That would bring us the best of both worlds. > > Or possibly tweak the sensitive tests (how many are there?) > to make clear in the output that they were not run for this > reason... That would probably require a new field in the > final report (ie. success-failure-todo-skipped or similar). > This could also signal WINETEST_INTERACTIVE tests so that > they aren't forgotten about... > > That said, I don't know much of this desktop business, so > I'm not sure how to put the detection logic in. The rest > should not be hard, I hope I'll find the time for them if we > decide to go this way.

Dec. 7, 2004

Re: No more winrash?

by Jakob Eriksson

Ferenc Wagner wrote: >Jakob Eriksson <jakov(a)vmlinux.org> writes: > > > >>> >>>If it really breaks the tests then definitely yes. >>> >>> > >I think it does provide much useful information which would >be largely lost if we resorted to manual testing. What's > > Good, I kind of hoped you thought so too. >more, winetest is not really up to that, as it doesn't ask >for a tag but relies on a command line option which people >would tend to forget. What I propose: make winetest detect >whether it's running on an interactive desktop or not, and >include this info in the header just like bRunningUnderWine. >Meanwhile add the tag dialog to winetest and separate or >mark the different reports on the webpage for easier >reference. That would bring us the best of both worlds. > >Or possibly tweak the sensitive tests (how many are there?) >to make clear in the output that they were not run for this > > I tried sending a patch for this, but it wasn't much loved and dropped. >reason... That would probably require a new field in the >final report (ie. success-failure-todo-skipped or similar). >This could also signal WINETEST_INTERACTIVE tests so that >they aren't forgotten about... > >That said, I don't know much of this desktop business, so >I'm not sure how to put the detection logic in. The rest > > Well, line 183 in dlls/gdi/tests/metafile.c detects rather nicely whether we are running in an interactive desktop or not. I could copy that logic to winetest.exe metafile.c : 183 ok(emr_processed, "EnumEnhMetaFile couldn't find EMR_EXTTEXTOUTA or EMR_EXTTEXTOUTW record\n"); ( http://test.winehq.org/data/200412021000/2000_JakobErikssonBW/gdi32:metafil… ) regards, Jakob Eriksson

Dec. 7, 2004

Re: Implemented CreateAsyncBindCtx

by Alexandre Julliard

Jacek Caban <jack(a)itma.pwr.wroc.pl> writes: > It's my tiny bug. RegsterObjectParam can fail only with E_OUTOFMEMORY > here, so checking it's return is > really not important, but to be correct at all, hres should be just > returned. No, that's worse than before, now you return an error while still allocating the object. You need to cleanup the allocated context when returning a failure. -- Alexandre Julliard julliard(a)winehq.org

Dec. 7, 2004

Re: Help with some strange debugging.

by Jon Griffiths

Hi Oliver, >I've also got a little patch for oleaut/varient.c to >allow number-string comparisons. There are a couple of >undocumented assumptions I've made,like what to return >for an empty of if the string isn't a number, and the >only thing I've been able to test with is 1 vb >application as I don't have windows, should I post it >to this list or to patch? If you need to test how the native dll works, please write a unit test case for the comparasons you are interested in (there are a _huge_ number of variant tests already defined in the dlls/oleaut32/tests directory). Run the tests manually from the tests directory as: WINEDLLOVERRIDES="oleaut32=n" wine ./oleaut32test.exe.so <testname> To check out the native versions behaviour (of course you will need a native oleaut32.dll in your fake c:\windows\system dir). for the builtin version run: WINETEST_PLATFORM="wine" WINEDLLOVERRIDES="oleaut32=b" wine ./oleaut32test.exe.so <testname> This will catch any regressions from your patch and ensure that future changes don't break your changes in any way. Cheers, Jon ===== "Don't wait for the seas to part, or messiahs to come; Don't you sit around and waste this chance..." - Live jon_p_griffiths(a)yahoo.com __________________________________ Do you Yahoo!? Meet the all-new My Yahoo! - Try it today! http://my.yahoo.com

Dec. 7, 2004

Re: Providing success stories

by Stefan Munz

Hi Hiji, can you provide me some more info. I think your part was to put the stories in some web-related format like HTML or maybe pdf, right? I can do this for those stories. When I'm done whats the next step? Mailing my version to wine-devel or who should I contact? Am Montag, 6. Dezember 2004 19:26 schrieb M-Halo: > It was in my que to do this type of project awhile > back, but I'll gladly hand the reponsibility over to > you if it means it will get done faster. Stefan, I > have a story or two I will email over to you! :) > > Thanks! > Hiji > <bigsnip> Regards, Stefan

Dec. 7, 2004

Re: No more winrash?

by Ferenc Wagner

Jakob Eriksson <jakov(a)vmlinux.org> writes: > Do you agree, should we stop using winrash? > > "Dmitry Timoshkov" <dmitry(a)baikal.ru> wrote: > >> "Jakob Eriksson" <jakov(a)vmlinux.org> wrote: >> >>> Well, I tried now marking the service as interactive, >>> but that didn't make any difference. >>> >>> So, what follows, deprecate Winrash? >> >> If it really breaks the tests then definitely yes. I think it does provide much useful information which would be largely lost if we resorted to manual testing. What's more, winetest is not really up to that, as it doesn't ask for a tag but relies on a command line option which people would tend to forget. What I propose: make winetest detect whether it's running on an interactive desktop or not, and include this info in the header just like bRunningUnderWine. Meanwhile add the tag dialog to winetest and separate or mark the different reports on the webpage for easier reference. That would bring us the best of both worlds. Or possibly tweak the sensitive tests (how many are there?) to make clear in the output that they were not run for this reason... That would probably require a new field in the final report (ie. success-failure-todo-skipped or similar). This could also signal WINETEST_INTERACTIVE tests so that they aren't forgotten about... That said, I don't know much of this desktop business, so I'm not sure how to put the detection logic in. The rest should not be hard, I hope I'll find the time for them if we decide to go this way. -- Feri.

Dec. 7, 2004

Re: gdi/metafile tests

by Dmitry Timoshkov

"Walt Ogburn" <reuben(a)ugcs.caltech.edu> wrote: > I have started working on some tests (attached here) for metafile > functions in gdi. If these seem reasonable, should I add them to your > metafile.c test code, or move yours to enhmetafile.c and start a new > metafile.h? It can't hurt anyway, and it's always helpful to have as much tests as possible. I think that "metafile" is a generic enough word to hold both type of tests: for old type metafiles and EMFs, so just add your new tests to existing metafile.c, -- Dmitry.

Dec. 7, 2004

Re: msvcrt: implement _dup (take 2)

by Juan Lang

--- Dmitry Timoshkov <dmitry(a)baikal.ru> wrote: > You need to close duplicated handle in the case of msvcrt_alloc_fd > failure. Ah, indeed. I'm working on _dup2, I'll correct and resend with that. Thanks Dmitry. --Juan __________________________________ Do you Yahoo!? Take Yahoo! Mail with you! Get it on your mobile phone. http://mobile.yahoo.com/maildemo

Dec. 6, 2004

Re: msvcrt: implement _dup (take 2)

by Dmitry Timoshkov

"Juan Lang" <juan_lang(a)yahoo.com> wrote: > + if (DuplicateHandle(GetCurrentProcess(), MSVCRT_fdesc[od].handle, > + GetCurrentProcess(), &handle, 0, > + !(MSVCRT_fdesc[od].wxflag & WX_DONTINHERIT), DUPLICATE_SAME_ACCESS)) > + { > + ret = msvcrt_alloc_fd(handle, MSVCRT_fdesc[od].wxflag); > + if (ret == -1) > + *MSVCRT__errno() = MSVCRT_EMFILE; > + } You need to close duplicated handle in the case of msvcrt_alloc_fd failure. -- Dmitry.

Dec. 6, 2004

Re: stub implementation for GetLastInputInfo and SetLayeredWindowAttributes

by Dmitry Timoshkov

"Mike McCormack" <mike(a)codeweavers.com> wrote: > +BOOL WINAPI GetLastInputInfo(PLASTINPUTINFO); ... > diff -u -r1.90 user32.spec > --- dlls/user/user32.spec 19 Oct 2004 21:10:17 -0000 1.90 > +++ dlls/user/user32.spec 6 Dec 2004 18:01:17 -0000 > @@ -263,6 +263,7 @@ > @ stdcall GetKeyboardState(ptr) > @ stdcall GetKeyboardType(long) > @ stdcall GetLastActivePopup(long) > +@ stdcall GetLastInputInfo() Number of parameters in header and spec files mismatch and there is no stub implementation of GetLastInputInfo at all. -- Dmitry.

Dec. 6, 2004

Re: Fedora Core 2 VM layout

by Robert Shearman

Kenneth Porter wrote: > There's a thread going on the fedora-devel list about exec-shield, > legacy_va_layout, and WINE: > > <https://www.redhat.com/archives/fedora-devel-list/2004-December/msg00132.ht…> > > > Some WINE experts might want to weigh in over there. Are these still > issues with the current WINE release? > No, they are no longer issues in wine and CrossOver due to us using our own loader which reserves the virtual memory addresses needed by programs. The problem is that Cedega doesn't do this. Their customers should ask them why they don't use the LGPL wine-preloader. Rob

Dec. 6, 2004

Fedora Core 2 VM layout

by Kenneth Porter

There's a thread going on the fedora-devel list about exec-shield, legacy_va_layout, and WINE: <https://www.redhat.com/archives/fedora-devel-list/2004-December/msg00132.ht…> Some WINE experts might want to weigh in over there. Are these still issues with the current WINE release?

Dec. 6, 2004

gdi/metafile tests

by Walt Ogburn

To Dmitry Timoshkov - I have started working on some tests (attached here) for metafile functions in gdi. If these seem reasonable, should I add them to your metafile.c test code, or move yours to enhmetafile.c and start a new metafile.h? Thanks, Walter

Dec. 6, 2004

Help with some strange debugging.

by Oliver Stieber

Hi, I kinda missed the bug bust lastnight but that hasn't stopped me bug hunting. Anyhow, I've been trying to fix a number of D3D problems using in Thief 3, winedbg isn't being too helpfull(The first breakpoint I set takes an age and trying to start off again an exception), so I've been trying to use relay to track down the problem. The problem is, when I turn on relay the app has an exception even earlier on and the debug log looks like this. 000c:Call d3d8.Direct3DCreate8(000000dc) ret=10c80251 000c:Call wined3d.WineDirect3DCreate(000000dc,00000008) ret=40720bc9 000c:trace:wine_d3d:WineDirect3DCreate Created WineD3D object @ 0x40435938 for d3d8 support 000c:trace:wine_d3d:WineDirect3DCreate Created WineD3D object @ 0x40435bb8 for d3d0 support 000c:trace:seh:EXC_RtlRaiseException code=c0000005 flags=0 addr=0x2 000c:trace:seh:EXC_RtlRaiseException info[0]=00000000 000c:trace:seh:EXC_RtlRaiseException info[1]=00000002 ....which is strange because there's no way that wine_d3d:WineDirect3DCreate can get called twice in a row like that, especially with a version of 0. Any ideas what's up? BTW, thief 3 was working a lot better with 200410~ than with 200412~cvs I've also got a little patch for oleaut/varient.c to allow number-string comparisons. There are a couple of undocumented assumptions I've made,like what to return for an empty of if the string isn't a number, and the only thing I've been able to test with is 1 vb application as I don't have windows, should I post it to this list or to patch? ___________________________________________________________ Win a castle for NYE with your mates and Yahoo! Messenger http://uk.messenger.yahoo.com

Dec. 6, 2004

Re: Genrate stdole32.tlb file, and install generated files

by Vincent Béron

Le lun 06/12/2004 à 07:03, Huw D M Davies a écrit : > On Sat, Dec 04, 2004 at 01:38:59PM -0500, Vincent Béron wrote: > > stdole32-generator.c file from Huw. > > Invocation from wineprefixcreate from me. > > > > Changelog: > > > Automatically create c:\windows\system\stdole32.tlb. > > > > Vincent > > The native version of stdole32.tlb is actually a resource only dll > that contains the typelib itself as TYPELIB resource #1. I think we > probably want to do likewise. I guess the easiest way (if we keep a winelib app) is to use {Begin,End,}UpdateResource{A,W} from kernel32.dll? Great, some more motivation to finish what I started to implement a couple months ago :) Vincent

Dec. 6, 2004

current CVS broken.

by Ivan Leo Puoti

I believe this patch http://www.winehq.com/hypermail/wine-cvs/2004/12/0081.html is causing this compile error on my system. make[2]: Entering directory `/path/to/wine/source/dlls/winmm/winejack' gcc -c -I. -I. -I../../../include -I../../../include -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o audio.o audio.c audio.c: In function `JACK_WaveInit': audio.c:902: warning: implicit declaration of function `wine_dlsym' audio.c:902: warning: assignment makes pointer from integer without a cast audio.c:903: warning: assignment makes pointer from integer without a cast audio.c:904: warning: assignment makes pointer from integer without a cast audio.c:905: warning: assignment makes pointer from integer without a cast audio.c:906: warning: assignment makes pointer from integer without a cast audio.c:907: warning: assignment makes pointer from integer without a cast audio.c:908: warning: assignment makes pointer from integer without a cast audio.c:909: warning: assignment makes pointer from integer without a cast audio.c:910: warning: assignment makes pointer from integer without a cast audio.c:911: warning: assignment makes pointer from integer without a cast audio.c:912: warning: assignment makes pointer from integer without a cast audio.c:913: warning: assignment makes pointer from integer without a cast audio.c:914: warning: assignment makes pointer from integer without a cast audio.c:915: warning: assignment makes pointer from integer without a cast audio.c:916: warning: assignment makes pointer from integer without a cast audio.c:934: warning: implicit declaration of function `strcpyW' audio.c:998: warning: implicit declaration of function `wine_dlclose' audio.c: In function `wodDevInterfaceSize': audio.c:1682: warning: implicit declaration of function `MultiByteToWideChar' audio.c:1682: error: `CP_ACP' undeclared (first use in this function) audio.c:1682: error: (Each undeclared identifier is reported only once audio.c:1682: error: for each function it appears in.) audio.c: In function `wodDevInterface': audio.c:1692: error: `CP_ACP' undeclared (first use in this function) audio.c: In function `widDevInterfaceSize': audio.c:2428: error: `CP_ACP' undeclared (first use in this function) audio.c: In function `widDevInterface': audio.c:2438: error: `CP_ACP' undeclared (first use in this function) make[2]: *** [audio.o] Error 1 make[2]: Leaving directory `/path/to/wine/source/wine/dlls/winmm/winejack' make[1]: *** [winmm/winejack] Error 2 make[1]: Leaving directory `/path/to/wine/source/wine/dlls' make: *** [dlls] Error 2 ____________________________________________________________ Libero ADSL: 3 mesi gratis e navighi a 1.2 Mega, senza costi di attivazione. Abbonati subito su http://www.libero.it

Dec. 6, 2004

Compiling wine fails

by Florian Goth

Patch: http://cvs.winehq.org/patch.py?id=14706 breaks compiling on my system(kernel-2.6.9; gcc 3.4.2 ) Reverting the patch fixes compiling. The patch produces the following Errors: make[2]: Entering directory `/home/sifff/wine/dlls/winmm/winejack' gcc -c -I. -I. -I../../../include -I../../../include -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -O2 -march=athlon-xp -m32 -mmmx -m3dnow -msse -ftracer -funroll-loops -fpeel-loops -funswitch-loops -fweb -funit-at-a-time -o audio.o audio.c audio.c: In function `JACK_WaveInit': audio.c:902: Warnung: implizite Deklaration der Funktion »wine_dlsym« audio.c:902: Warnung: Zuweisung erzeugt Zeiger von Ganzzahl ohne Typkonvertierung audio.c:903: Warnung: Zuweisung erzeugt Zeiger von Ganzzahl ohne Typkonvertierung audio.c:904: Warnung: Zuweisung erzeugt Zeiger von Ganzzahl ohne Typkonvertierung audio.c:905: Warnung: Zuweisung erzeugt Zeiger von Ganzzahl ohne Typkonvertierung audio.c:906: Warnung: Zuweisung erzeugt Zeiger von Ganzzahl ohne Typkonvertierung audio.c:907: Warnung: Zuweisung erzeugt Zeiger von Ganzzahl ohne Typkonvertierung audio.c:908: Warnung: Zuweisung erzeugt Zeiger von Ganzzahl ohne Typkonvertierung audio.c:909: Warnung: Zuweisung erzeugt Zeiger von Ganzzahl ohne Typkonvertierung audio.c:910: Warnung: Zuweisung erzeugt Zeiger von Ganzzahl ohne Typkonvertierung audio.c:911: Warnung: Zuweisung erzeugt Zeiger von Ganzzahl ohne Typkonvertierung audio.c:912: Warnung: Zuweisung erzeugt Zeiger von Ganzzahl ohne Typkonvertierung audio.c:913: Warnung: Zuweisung erzeugt Zeiger von Ganzzahl ohne Typkonvertierung audio.c:914: Warnung: Zuweisung erzeugt Zeiger von Ganzzahl ohne Typkonvertierung audio.c:915: Warnung: Zuweisung erzeugt Zeiger von Ganzzahl ohne Typkonvertierung audio.c:916: Warnung: Zuweisung erzeugt Zeiger von Ganzzahl ohne Typkonvertierung audio.c:934: Warnung: implizite Deklaration der Funktion »strcpyW« audio.c:998: Warnung: implizite Deklaration der Funktion »wine_dlclose« audio.c: In function `wodDevInterfaceSize': audio.c:1682: Warnung: implizite Deklaration der Funktion »MultiByteToWideChar« audio.c:1682: Fehler: »CP_ACP« nicht deklariert (erste Benutzung in dieser Funktion) audio.c:1682: Fehler: (Jeder nicht deklarierte Bezeichner wird nur einmal aufgeführt audio.c:1682: Fehler: für jede Funktion in der er auftritt.) audio.c: In function `wodDevInterface': audio.c:1692: Fehler: »CP_ACP« nicht deklariert (erste Benutzung in dieser Funktion) audio.c: In function `widDevInterfaceSize': audio.c:2428: Fehler: »CP_ACP« nicht deklariert (erste Benutzung in dieser Funktion) audio.c: In function `widDevInterface': audio.c:2438: Fehler: »CP_ACP« nicht deklariert (erste Benutzung in dieser Funktion) make[2]: *** [audio.o] Fehler 1 make[2]: Leaving directory `/home/sifff/wine/dlls/winmm/winejack' make[1]: *** [winmm/winejack] Fehler 2 make[1]: Leaving directory `/home/sifff/wine/dlls' make: *** [dlls] Fehler 2

Dec. 6, 2004