September 2003 - Wine-Devel

config error
by Moreno Sept. 2, 2003

Sept. 2, 2003

Hi, When i try to use the variable ${HOME} in the wine config file don't work. some one can tell me if there is a reson or is a bug? bye -- Moreno <morenoca(a)freemail.it>

4 3

AW: Windows Video Drivers on Linux
by Klaus Gerlicher Sept. 2, 2003

Sept. 2, 2003

What it does is to emulate win32k.sys and videoprt.sys functionality and hook the X server up to use any available driver for Win2K/XP. The display driver in windows is a two component model, one DLL and one SYS. The DLL (display driver) links to kernel-mode GDI (win32k) and calls EngXXX() functions inside it while the SYS (miniport) links to the VideoPort (and unfortunately to other NTOSKRNL exports). While the latter poses no difficulty since XP graphics drivers are supposed to only use exports from win32k and videoprt, one of the main difficulties will be to get the OpenGL ICD driver to run on top of Linux since it can potentially call any user-mode export which would require me to emulate all of the Windows user-mode environment. WINE could probably help a lot in this respect. I will let you know as soon as I have the latest Radeon driver running inside my prototype. Klaus -----Ursprüngliche Nachricht----- Von: Sylvain Petreolle [mailto:spetreolle(a)yahoo.fr] Gesendet: Monday, September 01, 2003 3:13 PM An: Steven Edwards; wine-devel(a)winehq.com Cc: KlausPG(a)PrivateTools.de Betreff: Re: Windows Video Drivers on Linux Hi Klaus and Steven, Since this project will provide Microsoft drivers functionnality, will it emulate vga.dll and others dlls ? I agree with the fact this sounds really interesting, but I dont see now in which case this could provide some gain to the linux user. Do some display exist and need really specific drivers to function ? > There is no code yet on this site but I would take this guy at his word as he is the one > that developed the Private ICE debugger for Linux. One of our developers with the > ReactOS project ported PICE to ReactOS so we could debug drivers. Well now it > seems he has decided to try and implement support for Windows Video drivers on > Linux. > This sounds interesting. > http://www.privatetools.de/ > > "I'd also like to announce the start of a new project called "MSCGDI" > (Microsoft Compatible Graphics Device Interface). ===== Sylvain Petreolle (spetreolle_at_users_dot_sourceforge_dot_net) ICQ #170597259 alias upsf='false ; while [ $? -ne 0 ] ; do cvs update -APd ; done 2>&1 |tee cvslog' "What if tomorrow the War could be over ?" Morpheus, in "Reloaded". ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

3 2

Re: faq merge #2 -- Alexandre please look over the first patch :)
by Alexandre Julliard Sept. 2, 2003

Sept. 2, 2003

Tom <twickline(a)skybest.com> writes: > changelog > > merge from lostwages faq It doesn't build here, that's because of the '&' in the rpmseek.com URL, I'm not sure what's the correct way to escape that: documentation/faq.sgml:1386:93:E: general entity "cx" not defined and no default entity documentation/faq.sgml:1781:26:E: an attribute value must be a literal unless it contains only name characters documentation/faq.sgml:1781:61:E: end tag for element "A" which is not open documentation/faq.sgml:1786:14:E: end tag for "ULINK" omitted, but its declaration does not permit this -- Alexandre Julliard julliard(a)winehq.com

2 1

Source release and download directory
by Jakob Eriksson Sept. 2, 2003

Sept. 2, 2003

Source release and download directory: http://vmlinux.org/jakov/Wine/

3 7

Re: Move Wine internal headers
by Alexandre Julliard Sept. 2, 2003

Sept. 2, 2003

Vincent Béron <vberon(a)mecano.gme.usherb.ca> writes: > winegcc doesn't include eg /usr/include, so the headers referencing > internal ones (mostly OLE related) fail. I thought it was cleaner to > move wine internal stuff than to break down the includedir variable in > Makefile to get to the parent of /usr/include/wine, ie /usr/include. OK, I see. I think the idea with winegcc at this point is that if you install Wine in a non-standard directory, you have to specify the include path yourself, just like you need to ensure the Wine tools are in your PATH. Besides, this shouldn't be an issue once the standard includes are fixed to no longer reference the wine/obj_* ones. -- Alexandre Julliard julliard(a)winehq.com

2 2

Re: Move Wine internal headers
by Alexandre Julliard Sept. 2, 2003

Sept. 2, 2003

Vincent Béron <vberon(a)mecano.gme.usherb.ca> writes: > Changelog: > Move the Wine internal headers to includedir/wine/wine rather than > includedir/wine. Why do you want to do that? -- Alexandre Julliard julliard(a)winehq.com

1 0

Fwd: wine without w*nd*ws
by Sylvain Petreolle Sept. 2, 2003

Sept. 2, 2003

It seems winecheck needs a fix here, right ? > >>> Checking drive Z settings: > 022. Checking Path option... > SUSPICIOUS > (/ is not writable for you). regedit should return a success message, shouldn't it ? > /usr/local/wine/programs/regedit$ regedit ../../winedefault.reg > Could not stat /mnt/fd0 (No such file or directory), ignoring drive > A: ===== Sylvain Petreolle (spetreolle_at_users_dot_sourceforge_dot_net) ICQ #170597259 alias upsf='false ; while [ $? -ne 0 ] ; do cvs update -APd ; done 2>&1 |tee cvslog' "What if tomorrow the War could be over ?" Morpheus, in "Reloaded". ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

1 0

Re: Janitorial: Include statements should use <> instead of ""
by Alexandre Julliard Sept. 2, 2003

Sept. 2, 2003

Andrey Warkentin <andyw(a)imsa.edu> writes: > Currently done: wine/controls/* and wine/dlls/gdi/* (with the > exception of wine/dlls/gdi/tests/generated.c) > > ChangeLog > Include statements use <> instead of "" in files in wine/controls > and wine/dlls/gdi This was discussed already, there's no reason to change the C files, only the headers actually matter (and these are fixed now). -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: Fix comctl32 tests
by Alexandre Julliard Sept. 2, 2003

Sept. 2, 2003

"Dimitrie O. Paun" <dpaun(a)rogers.com> writes: > ChangeLog > DPA_Create is exported by ordinal only, do not import it by name. That shouldn't be necessary, it's automatically handled when resolving the import. That's probably a bug in the mingw import library. -- Alexandre Julliard julliard(a)winehq.com

1 0

dinput/mouse handing
by Michael Schlüter Sept. 1, 2003

Sept. 1, 2003

Hi, I still have a problem with mouse handling in the demo of "Star Trek Elite Force II". It looks like the game initializes the mouse with: 0009:trace:dinput:SysMouseAImpl_SetCooperativeLevel (this=0x40403e00,0x00000000,0x00000005) 0009:trace:dinput:SysMouseAImpl_SetCooperativeLevel cooperative level : DISCL_EXCLUSIVE DISCL_FOREGROUND but then didn't call GetDeviceState to get the input. So the game is waiting for an event? If that is a correct behaviour of a windows program with a cooperative level of "DISCL_EXCLUSIVE" then we have to change that in dinput/mouse/main.c: /* low-level mouse hook */ static LRESULT CALLBACK dinput_mouse_hook( int code, WPARAM wparam, LPARAM lparam ) { ... if (dwCoop & DISCL_NONEXCLUSIVE) { /* pass the events down to previous handlers (e.g. win32 input) */ ret = CallNextHookEx( This->hook, code, wparam, lparam ); } else ret = 1; /* ignore message */ return ret; } to always call "CallNextHookEx". After fixing this here the game works properly. Following a part of the trace after the fix: 0009:trace:dinput:dinput_mouse_hook queueing 244 at offset 0 (queue head 0 / size 16) 0009:trace:dinput:dinput_mouse_hook queueing -42 at offset 4 (queue head 1 / size 16) 0009:trace:dinput:dinput_mouse_hook msg 200 pt 844 470 (W=0) 0009:trace:dinput:dinput_mouse_hook (X: 244 - Y: -42 L: 00 M: 00 R: 00) 0009:Call ntdll.RtlLeaveCriticalSection(40403e80) ret=4a71e424 0009:Ret ntdll.RtlLeaveCriticalSection() retval=00000000 ret=4a71e424 0009:Call user32.CallNextHookEx(00010027,00000000,00000200,40de24ec) ret=4a71e43f 0009:Call ntdll.GlobalLock16(00000197) ret=40fce87a 0009:Ret ntdll.GlobalLock16() retval=403ec850 ret=40fce87a 0009: get_next_hook( handle=0x10027 ) 0009: get_next_hook() = 0 { next=(nil), id=0, pid=0000, tid=0000, proc=(nil), prev_unicode=0, next_unicode=0, module=L"" } 0009:Ret user32.CallNextHookEx() retval=00000000 ret=4a71e43f 0009:Ret hook proc 0x4a71e290 (id=WH_MOUSE_LL,code=0,wp=00000200,lp=40de24ec) retval=000000000009: finish_hook_chain( id=14 ) 0009: finish_hook_chain() = 0 0009: send_message( id=0009, type=7, flags=0, win=0x10021, msg=00000200, wparam=00000000, lparam=00000000, x=844, y=470, time=a398f331, info=00010021, timeout=-1, callback=(nil), data={} )0009: send_message() = 0 0009:Ret user32.SendInput() retval=00000001 ret=41429a43 Bye, Michael

1 0

AW: AW: Windows Video Drivers on Linux
by Klaus Gerlicher Sept. 1, 2003

Sept. 1, 2003

Gerhard, I haven't really abandoned pICE, it's just that I didn't have the time nor guts to finish with it. Kernel development went ahead in big steps at that time and I couldn't follow anymore. I will now rather pursue development of the GDI emulation layer since this is a fresh start while pICE has cost me a lot of time and nerves already. I will gladly continue with pICE if I have a good reason to do so. Technically there's no reason to discontinue pICE, I had just started to get it running on SMP machines and was working on the serial link stuff. It will probably not compile nor run at the moment on 2.4 or 2.5/2.6 kernels since I originally had done most of the work on 2.2. Hope there's not to many changes with page fault handling et al. Please feel free to do whatever it needs to get this back on track... I'm honored that so many people are wanting to use it. Also let me know where I can help. Klaus -----Ursprüngliche Nachricht----- Von: Gerhard W.Gruber [mailto:sparhawk(a)gmx.at] Gesendet: Montag, 1. September 2003 21:55 An: wine-devel(a)winehq.com Cc: Klaus Gerlicher Betreff: Re: AW: Windows Video Drivers on Linux On Mon, 1 Sep 2003 16:28:58 +0200, Klaus Gerlicher <KlausPG(a)ati.com> wrote: >What it does is to emulate win32k.sys and videoprt.sys functionality and >hook the X server up to use any available driver for Win2K/XP. > >The display driver in windows is a two component model, one DLL and one SYS. >The DLL (display driver) links to kernel-mode GDI (win32k) and calls >EngXXX() functions inside it while the SYS (miniport) links to the VideoPort >(and unfortunately to other NTOSKRNL exports). While the latter poses no >difficulty since XP graphics drivers are supposed to only use exports from >win32k and videoprt, one of the main difficulties will be to get the OpenGL >ICD driver to run on top of Linux since it can potentially call any >user-mode export which would require me to emulate all of the Windows >user-mode environment. WINE could probably help a lot in this respect. > >I will let you know as soon as I have the latest Radeon driver running >inside my prototype. Oh! Seems I was wrong with my assumption that you couldn't be contacted. :) Good! :) Could you tell me why you abandoned pICE? Is there a specific reason for this or only personel? If there is some technical reason I would like to know about this, as I'm quite interested in this project and I really would like to continue it in order to have some decent debugger for wine as well. -- Gerhard Gruber Für jedes menschliche Problem gibt es immer eine einfache Lösung: Klar, einleuchtend und falsch. (Henry Louis Mencken)

1 0

Windows Video Drivers on Linux
by Steven Edwards Sept. 1, 2003

Sept. 1, 2003

Hello, There is no code yet on this site but I would take this guy at his word as he is the one that developed the Private ICE debugger for Linux. One of our developers with the ReactOS project ported PICE to ReactOS so we could debug drivers. Well now it seems he has decided to try and implement support for Windows Video drivers on Linux. http://www.privatetools.de/ "I'd also like to announce the start of a new project called "MSCGDI" (Microsoft Compatible Graphics Device Interface). The project's goal is to write an emulation layer that makes it possible to install Windows native display drivers on Linux running an Xserver. I have already started to code a kernel module that serves as the wrapper around display driver and miniport, emulating the Win32k.sys and VideoPrt.sys API. So far I have a been able to bring up VGA.DLL and VGA.SYS from Windows 2000 Professional and use it to draw some basic stuff on a VGA based adapter. If someone is interested in supporting development of any of those projects, please write to KlausPG(a)PrivateTools.de. I will put up a project website in the next couple of days on which I will offer some basic demonstration of that idea." This sounds interesting. Thanks Steven __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com

3 2

Re: add missing shell32 functions
by Vincent Béron Sept. 1, 2003

Sept. 1, 2003

Le lun 01/09/2003 à 02:39, Dave Miller a écrit : > This patch begins reconciling the windows and wine spec files (bugzilla > bug 556) If I've done this correctly and noone objects I'll follow up > with more additions. > > ChangeLog > Add some missing functions to shell32.spec > > --- /usr/src/wine/dlls/shell32/shell32.spec 2003-09-01 > 02:05:32.000000000 -0400 > +++ shell32.spec 2003-09-01 00:37:40.000000000 -0400 > @@ -159,7 +159,7 @@ > 169 stdcall SHDestroyPropSheetExtArray(long) > 170 stdcall SHReplaceFromPropSheetExtArray(long long long long) > 171 stdcall PathCleanupSpec(ptr ptr) PathCleanupSpecAW > - 172 stdcall SHCreateLinks(long str ptr long ptr) > + 172 stub SHCreateLinks Why remove this one? It's in shlfolder.c... Vincent

2 1

wine SIGSEGV at startup
by Dimitrie O. Paun Sept. 1, 2003

Sept. 1, 2003

Hi folks, For a few days now, I have a lot of problems with wine. I've managed to get it going a few days back, but I can't remember how. Now it just seg faults at startup. I just did a: [dimi(a)dimi wine.build]$ make -s clean [dimi(a)dimi wine.build]$ ../wine.src/configure --with-ntpd --silent && make -s depend && make -s [root(a)dimi wine.build]# make -s install but that did not fix it: [dimi(a)dimi dimi]$ which wine /usr/local/bin/wine [dimi(a)dimi dimi]$ wine Segmentation fault [dimi(a)dimi dimi]$ gdb wine GNU gdb Red Hat Linux (5.3post-0.20021129.18rh) Copyright 2003 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux-gnu"... (gdb) run Starting program: /usr/local/bin/wine Program received signal SIGSEGV, Segmentation fault. 0x420ebe3c in __libc_pthread_init () from /lib/tls/libc.so.6 (gdb) Am I the only one with this problem? -- Dimi.

5 7

msi.dll broken with yacc in current cvs
by Stefan Leichter Sept. 1, 2003

Sept. 1, 2003

Hello, i can not compile msi.dll on one of my systems. make aborts with: yacc -d -t ../../../wine/dlls/msi/sql.y yacc: e - line 69 of "../../../wine/dlls/msi/sql.y", syntax error %pure-parser ^ make[2]: *** [y.tab.c] Error 1 make[2]: Leaving directory `/usr/src/wine-build/dlls/msi' make[1]: *** [msi] Error 2 make[1]: Leaving directory `/usr/src/wine-build/dlls' make: *** [dlls] Error 2 The second system compiles fine. It uses bison instead of yacc. Both systems are SuSE 7.3 > rpm -qa | grep -e bison -e yacc yacc-91.7.30-379 bison-1.28-127 I know i can install bison and it will compile, but i think this needs to be fixed. Bye Stefan

3 3

New EXE
by Jakob Eriksson Sept. 1, 2003

Sept. 1, 2003

http://vmlinux.org/jakov/Wine/regrtest.exe Should now work on Win9x too. Works on ME at least.

6 9

Re: Bugzilla bug #556
by Dave Miller Sept. 1, 2003

Sept. 1, 2003

Thanks, I hoped it would be that simple. I'll begin work on this and see if anyone yells my patches are wrong. :)

1 0

Re: New EXE
by Ivan Leo Murray-Smith Sept. 1, 2003

Sept. 1, 2003

>Yes, it would be nice to have more frequent releases, but we would have >trouble labeling them...unless we stick to the build date. But in that >case, we have to have a well understood convention on what YYYYMMDD >means in terms of time, and we have to stick to it (well, the person >building this should). Any takers? What about an automatic build?

2 1