- wine-devel - winehq.org

Non-working patch for 3GB of memory allocation
by Shachar Shemesh 28 Jul '04

28 Jul '04

Ok, this patch would probably not be appropriate even if it did work. The surprising thing, however, is that it doesn't. The idea was simple. We use mmap as usual until mmap starts to fail with no memory. When that happens, we switch to allocating memory with malloc, which allegably knows how to use "brk" in order to allocate memory from the lower 1GB area. The patch is against 20040716. The attached program tries to repeatedly allocate ~100MB, until it fails. It is compiled for advanced server (i.e. - it has 3GB of address space, but that's besides the point). When actually run (through strace), one can see the mmaps being carried out and successful, and then the mmap that fails (no memory). Then malloc is attempted, which tries mmap, then brk, and then mmap again. All fail. This is the point where I stop understanding. Does anyone have any explanation as to why malloc fails? Does wine prevent large scale use of the lower area due to some reason? Any ideas would be appreciated. Shachar ? runconfig ? dlls/ntdll/.virtual.c.swp Index: dlls/ntdll/virtual.c =================================================================== RCS file: /home/wine/wine/dlls/ntdll/virtual.c,v retrieving revision 1.37 diff -u -r1.37 virtual.c --- dlls/ntdll/virtual.c 22 Jun 2004 03:02:35 -0000 1.37 +++ dlls/ntdll/virtual.c 26 Jul 2004 13:53:41 -0000 @@ -78,6 +78,7 @@ /* Per-view flags */ #define VFLAG_SYSTEM 0x01 /* system view (underlying mmap not under our control) */ #define VFLAG_VALLOC 0x02 /* allocated by VirtualAlloc */ +#define VFLAG_MALLOC 0x04 /* allocated using malloc */ /* Conversion from VPROT_* to Win32 flags */ static const BYTE VIRTUAL_Win32Flags[16] = @@ -168,9 +169,13 @@ DPRINTF( "View: %p - %p", addr, addr + view->size - 1 ); if (view->flags & VFLAG_SYSTEM) DPRINTF( " (system)\n" ); - else if (view->flags & VFLAG_VALLOC) - DPRINTF( " (valloc)\n" ); - else if (view->mapping) + else if (view->flags & VFLAG_VALLOC) { + DPRINTF( " (valloc" ); + if (view->flags & VFLAG_MALLOC) + DPRINTF( " using malloc)\n" ); + else + DPRINTF( ")\n" ); + } else if (view->mapping) DPRINTF( " %p\n", view->mapping ); else DPRINTF( " (anonymous)\n"); @@ -348,7 +353,12 @@ */ static void delete_view( struct file_view *view ) /* [in] View */ { - if (!(view->flags & VFLAG_SYSTEM)) unmap_area( view->base, view->size ); + if (!(view->flags & VFLAG_SYSTEM)) { + if( !(view->flags & VFLAG_MALLOC) ) + unmap_area( view->base, view->size ); + else + free( view->base ); + } list_remove( &view->entry ); if (view->mapping) NtClose( view->mapping ); free( view ); @@ -559,6 +569,7 @@ { void *ptr; NTSTATUS status; + int used_malloc=0; if (base) { @@ -602,7 +613,19 @@ { if ((ptr = wine_anon_mmap( NULL, view_size, VIRTUAL_GetUnixProt(vprot), 0 )) == (void *)-1) { - if (errno == ENOMEM) return STATUS_NO_MEMORY; + if (errno == ENOMEM) + { + /* mmap allocation failed. Let's see if we can try malloc, and whether it is going to be more lucky */ + FIXME("About to try malloc\n"); + if( /* Unix protection is not malloc compatible, or */ (ptr = malloc( size ))!=NULL ) + { + used_malloc=1; + goto memory_allocated; + } else { + FIXME("malloc failed\n"); + return STATUS_NO_MEMORY; + } + } return STATUS_INVALID_PARAMETER; } /* if we got something beyond the user limit, unmap it and retry */ @@ -623,8 +646,17 @@ munmap( (char *)ptr + size, view_size - size ); } +memory_allocated: status = create_view( view_ret, ptr, size, vprot ); - if (status != STATUS_SUCCESS) unmap_area( ptr, size ); + if( used_malloc && status==STATUS_SUCCESS ) + (*view_ret)->flags|=VFLAG_MALLOC; + else if (status != STATUS_SUCCESS) + { + if( !used_malloc ) + unmap_area( ptr, size ); + else + free( ptr ); + } return status; }

2 6

delayed unloading of .so in WINE
by Santosh Siddheshwar 28 Jul '04

28 Jul '04

Hi, Is there any way to specify in config file or any other place, a way to prevent/delay a shared object from being unloaded till the application using it terminates? In dlopen there is a flag RTLD_NODELETE which keeps the loaded shared object in memory even after dlclose is called. The shared object is unloaded only when the app exits. Do we have some way to do this in WINE? Or does any feature in Windows necessitate implementing this kind of behaviour in WINE? I can think of VC++ linker flags /DELAYLOAD and /DELAY:unload which might need the use of such mechanism. Regards Santosh Siddheshwar ********************************************************************* Disclaimer: The information in this e-mail and any attachments is confidential / privileged. It is intended solely for the addressee or addressees. If you are not the addressee indicated in this message, you may not copy or deliver this message to anyone. In such case, you should destroy this message and kindly notify the sender by reply email. Please advise immediately if you or your employer does not consent to Internet email for messages of this kind. *********************************************************************

2 1

generation date/version of the (online) wine documentation
by Jeroen Janssen 28 Jul '04

28 Jul '04

Hi, I have a few questions: * is it possible to add the date/version in the online wine documentation at http://www.winehq.com/site/documentation (for the user, devel docs) * when exactly are these pages generated? (nightly/daily/?) best regards, Jeroen

2 1

handling IUnknown/IRemUnknown for (outproc) objects
by Jeroen Janssen 28 Jul '04

28 Jul '04

Hello, After last weeks discussion on the "unhandled interface" message in CFProxy_QueryInterface I was getting, we concluded (if I'm correct) that this is part of the "IRemUnknown" handling that is not (yet) implemented correctly in the wine CVS tree. I'm trying to figure out exactly where in the (OLE) code, this should be handled. If someone could point me in the right direction I would appreciate it very much. I think it would also be helpfull if there was some "fixme" logging so other people can also see if they hit upon the same problem (since it took a while to finally figure out the problem). --- Jeroen

3 3

Re: change the nt service pack version from 6 to 6a, correct win2k3 name
by Ivan Leo Puoti 28 Jul '04

28 Jul '04

I've found this hex value in user32.dll 5e07c is this good or bad? Ivan.

1 0

Re: DCOM: Document wrong behaviour for IRunningObjectTable
by Robert Shearman 28 Jul '04

28 Jul '04

Robert Shearman wrote: > Changelog: > Document wrong behaviour for IRunningObjectTable. Sorry, the changelog for this patch should have been as follows: Mike Hearn <mh(a)codeweavers.com> Robert Shearman <rob(a)codeweavers.com> Document wrong behaviour for IRunningObjectTable.

1 0

Re: change the nt service pack version from 6 to 6a, correct win2k3 name
by Andreas Mohr 28 Jul '04

28 Jul '04

Hi, On Wed, Jul 28, 2004 at 11:39:30AM +0200, Ivan Leo Puoti wrote: > I'm not 100% sure this patch is correct, please let me know if it isn't. > BTW at line 342 of dlls/ntdll/version.c I read /* FIXME: Not sure, should be > verified with a Win2K3 dll */ > how can this be verified? Easy, take several W2K3 system DLLs and kick them through winedump (or pedump.exe) to verify whether their RtlImageNtHeader(hmod)->OptionalHeader.MajorOperatingSystemVersion value (i.e. their MajorOperatingSystemVersion value) is 7 like our Wine code assumes here. Otherwise you'll have to find out other characteristic DLL version number differences of these DLLs compared to WinXP to be able to properly return the WIN2K3 version for these AND ONLY these... Andreas Mohr

1 0

icons contribuition
by Marcio Esper 28 Jul '04

28 Jul '04

Hello, My name is Marcio Esper. The Ivan tell me than I can send to you using this e-mail some icons. >We could do with some better icons, email wine-devel(a)winehq.com if you >want to contribute I made a new icon to be used with wine. 128x128, 64x64, 48x48, 32x32, 16x16. I hope you like it. The icons are made in Kpovmodeler on Mandrake linux 10 AMD64 and you can use and spread it without any restrition just geve me credits puting my name in the readmes and or were you think a good place to talk about it. ;p If we whant more models and sizes, let me know. Best regards, Marcio Esper

3 5

RelayExclude
by Diego 'Flameeyes' Pettenò 28 Jul '04

28 Jul '04

Hi, I've a question about RelayExclude setting in [Debug] section of ~/.wine/config : I was trying to debug the load of ClrMamePro watching at the relay output, but there's a lot of call of ntdll.RtlEnterCriticalSection ntdll.RtlLeaveCriticalSection and so on. I already added them to RelayExclude last year when I debugged another app, but seems like now this setting is ignored. I also tried to add the complete ntdll.RtlEnterCriticalSection name, but nothing changed. Any suggestion? TIA, -- Diego "Flameeyes" Pettenò dgp85(a)users.sourceforge.net - http://flameeyes.web.ctonet.it/

4 3

Re: Make wine honor LC_CTYPE and LC_MESSAGES
by Dmitry Timoshkov 28 Jul '04

28 Jul '04

"Shachar Shemesh" <shachar(a)lingnu.com> wrote: > http://support.microsoft.com/default.aspx?scid=kb;en-us;258047 says you > are wrong. My personal experience says you are wrong too, but that's > besides the point. You are misinterpreting that MSDN article, especially part about user locale. Since there is no official API to change user locale, what they call user locale settings are registry overrides for locale data. I already mentioned that on my english win2k with locale in Control Panel set to russian both GetSystemDefaultLCID and GetUserDefaultLCID return 0419 (russian). That dismisses MSDN and your statements. Thread locale is completely unrelated thing. -- Dmitry.

2 1

AmigaOS4
by Manuel Fink 27 Jul '04

27 Jul '04

Hello I has here a small question. That appeared Amiga OS4 Prerelease for some time and it seems a good and stable system to be. will it give in the near future WINE also for the AmigaOS4? Greeting Manuel

1 0

MUI setup - preliminary conclusions
by Shachar Shemesh 27 Jul '04

27 Jul '04

Ok, here is the preliminary conclusions from Windows XP MUI: There are two setups in the system. One is the "language for the default user and new user accounts". It affects the language people get when they create a new user, and the language the login dialog is in. To change that one, you need to run the MUI setup program. A restart is needed to change this. The second is an extra dialog in the Regional Settings dialog under the "languages" tab, and it selects the language the current user will have. You need to log off and log on in order to change this one. At the moment, my system is set up with English, Hebrew and Italian installed. I'm trying to figure out what exactly is passed to FindResourceEx when FindResource is called. So far, it seems that "LANG_NEUTRAL, SUBLANG_NEUTRAL" is used, but it's not definite yet. One thing of interest, however, is that when LANG_NEUTRAL, SUBLANG_DEFAULT is passed, the lookup is for the language used in the second case (the user UI language), and when LANG_NEUTRAL, SUBLANG_SYS_DEFAULT, the first one is used. It seems to me that there is no need for wine to support two separate languages here. Does anyone disagree with this? Given the above settings, my current test program currently tests the order between English(US), English(UK), English(Neutral), Italian(Italy), Italian(Neutral), Hebrew(Default), Hebrew(Neutral), Neutral and Neutral(Default). Are there any other languages I should test for order by? Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/

1 0

Re: DCOM: Pass -Embedding switch to EXE servers, more tracing
by Jeroen Janssen 27 Jul '04

27 Jul '04

James Hawkins wrote: >WCHAR is a wide (unicode) character. sizeof(embedding)/sizeof(WCHAR) >will return the length of the strength in characters and not the size >of it if I'm not mistaken. > > Yes, and I think you will want to have the length in characters when declaring a (C) array in the example code below: With static const WCHAR embedding[] = { ' ', '-','E','m','b','e','d','d','i','n','g',0 }; You will want WCHAR command[MAX_PATH+(sizeof(embedding)/sizeof(WCHAR)+1]; instead of WCHAR command[MAX_PATH+sizeof(embedding)+1]; Because if sizeof(WCHAR) == 2, then command will be strlen(embedding) to large. >On Mon, 26 Jul 2004 18:24:48 +0200, Jeroen Janssen <japj(a)xs4all.nl> wrote: > > >>Mike Hearn wrote: >> >> >>>ChangeLog: >>>Pass -Embedding switch to EXE servers, more tracing >>> >>> >>>diff -u -p -r1.15 rpc.c >>>--- dlls/ole32/rpc.c 15 Jul 2004 22:07:44 -0000 1.15 >>>+++ dlls/ole32/rpc.c 21 Jul 2004 22:43:59 -0000 >>>@@ -471,8 +471,10 @@ create_server(REFCLSID rclsid) { >>> char buf[200]; >>> HRESULT hres = E_UNEXPECTED; >>> char xclsid[80]; >>>- WCHAR dllName[MAX_PATH+1]; >>>- DWORD dllNameLen = sizeof(dllName); >>>+ WCHAR exe[MAX_PATH+1]; >>>+ DWORD exelen = sizeof(exe); >>>+ static const WCHAR embedding[] = { ' ', '-','E','m','b','e','d','d','i','n','g',0 }; >>>+ WCHAR command[MAX_PATH+sizeof(embedding)+1]; >>> >>> >>On a side note, what exactly is a WCHAR? >>Is it a 'char' or a 'unicode char' (2bytes)? >> >>This in relation to sizeof(embedding) instead of >>sizeof(embedding)/sizeof(WCHAR)? >>--- >>Jeroen >> >> >> >> > > > >

2 2

Re: Make wine honor LC_CTYPE and LC_MESSAGES
by Shachar Shemesh 27 Jul '04

27 Jul '04

Following a discussion with Alexandre on IRC, here is a revised patch. This one doesn't touch the LC_MESSAGE, as these do not affect the user locale. Further work will be necessary on supporting MUI like language checking. Shachar Shemesh wrote: > Changelog: > Shachar Shemesh <winecode(a)shemesh.biz> > dlls/kernel/locale.c > > * System default locale in Windows determines the ANSI encoding > (LC_CTYPE on Unix) -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/

5 18

dinput.dll: mouse didn't work
by Michael Schlüter 26 Jul '04

26 Jul '04

Hi, I've a small problem with wine (cvs from today) when trying to play a game that uses dinput.dll. The game starts fine, keyboard inputs works but the mouse cursor didn't move. I had a look at the source code of dinput/mouse.c and the trace messages of dinput. But there is one thing I don't understand. The callback function for the mouse (dinput_mouse_hook) is never called. The initialising look good: trace:dinput:SysMouseAImpl_Acquire (this=0x40269480) trace:hook:set_windows_hook WH_MOUSE_LL 0x40dd64e0 0 -> 0x20028 trace:dinput:SysMouseAImpl_Acquire Warping mouse to 512 - 384 trace:dinput:SysKeyboardAImpl_Unacquire (this=0x40269db8) trace:dinput:SysKeyboardAImpl_SetEventNotification (this=0x40269db8,0x00000124) trace:dinput:SysKeyboardAImpl_Acquire (this=0x40269db8) trace:dinput:SysKeyboardAImpl_Acquire (this=0x40269db8) trace:dinput:SysMouseAImpl_Acquire (this=0x40269480) ... And later when pressing a mouse button: trace:hook:HOOK_CallHooks calling hook in thread 0013 WH_MOUSE_LL code 0 wp 200 lp 4071d074 But then there is no other dinput message. Shouldn't there be a call of the mouse callback function? Bye, Michael

3 6

LockWindowUpdate status
by Diego 'Flameeyes' Pettenò 26 Jul '04

26 Jul '04

Hi, I was trying to debug wine while using ClrMamePro to fix the Bug #2387 I reported (the main windows doesn't reappear after it's hide). The way of ShowWindow() function seems not to be the right one, because it seems not to be called when the window should shown up after hide. So I started following the messages way, starting by fixme:dc:LockWindowUpdate ((nil)), partial stub! fixme:dc:LockWindowUpdate (0x4007a), partial stub! fixme:dc:LockWindowUpdate ((nil)), partial stub! which seems to be more likely to be wine error than err:dc:DCE_FreeWindowDCE [0x30094] GetDC() without ReleaseDC()! which seems (at a first sight) a program error. So I opened windows/dce.c to search for the function, and I found a Mike's comment: /* This function is fully implemented by the following patch: * * http://www.winehq.org/hypermail/wine-patches/2004/01/0142.html * * but in order to work properly, it needs the ability to invalidate * DCEs in other processes when the lock window is changed, which * isn't possible yet. * -mike */ at this point I downloaded the patch and tried to apply but seems not to be appliable automatically (I'll try to apply it by hand because I haven't time now). My question is if there's some update on the status of LockWindowUpdate, because Mike's comment seems to point out that the patch won't work properly. It this is unrelated to my problem, I think I'll start trying random things to found out where the problem is :) Regards, -- Diego "Flameeyes" Pettenò dgp85(a)users.sourceforge.net - http://flameeyes.web.ctonet.it/

2 1

Re: Localization of devenum and minor corrections
by Marcelo Duarte 26 Jul '04

26 Jul '04

Resend. Changelog: Marcelo Duarte <wine-devel(a)bol.com.br> Localization to Portuguese (devenum) and minor corrections (winmm, progman, winmine). Index: dlls/devenum/devenum.rc =================================================================== RCS file: /home/wine/wine/dlls/devenum/devenum.rc,v retrieving revision 1.7 diff -u -u -r1.7 devenum.rc --- dlls/devenum/devenum.rc 23 Jul 2004 19:08:44 -0000 1.7 +++ dlls/devenum/devenum.rc 26 Jul 2004 21:36:02 -0000 @@ -51,3 +51,12 @@ 9 "Dispositivo WaveOut di Default" 10 "Dispositivo MidiOut di Default" } + +STRINGTABLE DISCARDABLE +LANGUAGE LANG_PORTUGUESE, SUBLANG_DEFAULT +{ + 7 "DirectSound padrão" + 8 "DirectSound: %s" + 9 "Dispositivo padrão WaveOut" + 10 "Dispositivo padrão MidiOut" +} Index: dlls/winmm/winmm_res.rc =================================================================== RCS file: /home/wine/wine/dlls/winmm/winmm_res.rc,v retrieving revision 1.15 diff -u -u -r1.15 winmm_res.rc --- dlls/winmm/winmm_res.rc 13 Jul 2004 23:36:37 -0000 1.15 +++ dlls/winmm/winmm_res.rc 26 Jul 2004 21:36:10 -0000 @@ -1,4 +1,4 @@ -/* Multimedia resources (MMSYSTEM.DLL & WINMM.DLL +/* Multimedia resources (MMSYSTEM.DLL & WINMM.DLL) * * Copyright (c) 1999, Eric Pouech * Index: programs/progman/Pt.rc =================================================================== RCS file: /home/wine/wine/programs/progman/Pt.rc,v retrieving revision 1.5 diff -u -u -r1.5 Pt.rc --- programs/progman/Pt.rc 4 Oct 2003 04:21:19 -0000 1.5 +++ programs/progman/Pt.rc 26 Jul 2004 21:36:14 -0000 @@ -38,7 +38,7 @@ MENUITEM "Sai&r do Windows...", PM_EXIT } POPUP "&Opções" { - MENUITEM "&Autoorganizar", PM_AUTO_ARRANGE + MENUITEM "&Auto organizar", PM_AUTO_ARRANGE MENUITEM "&Minimizar na execução", PM_MIN_ON_RUN MENUITEM "&Salvar alterações ao sair", PM_SAVE_SETTINGS } Index: programs/winemine/rsrc.rc =================================================================== RCS file: /home/wine/wine/programs/winemine/rsrc.rc,v retrieving revision 1.15 diff -u -u -r1.15 rsrc.rc --- programs/winemine/rsrc.rc 19 Jul 2004 19:34:26 -0000 1.15 +++ programs/winemine/rsrc.rc 26 Jul 2004 21:36:18 -0000 @@ -32,14 +32,13 @@ #include "Ru.rc" #include "Si.rc" +LANGUAGE LANG_NEUTRAL,SUBLANG_NEUTRAL IDA_WINEMINE ACCELERATORS DISCARDABLE { VK_F2, IDM_NEW, VIRTKEY, NOINVERT "X", IDM_EXIT, VIRTKEY, ALT, NOINVERT } - -LANGUAGE LANG_NEUTRAL,SUBLANG_NEUTRAL /* BINRES winemine.ico */ WINEMINE ICON MOVEABLE winemine.ico

1 0

Re: server/context_i386.c
by Joe Gainey 26 Jul '04

26 Jul '04

here are the build errors I am seeing: make[2]: Leaving directory `/home/viper/d/jgainey/build/WINE/wine-20040716/programs/winhelp' make[2]: Entering directory `/home/viper/d/jgainey/build/WINE/wine-20040716/programs/winver' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/home/viper/d/jgainey/build/WINE/wine-20040716/programs/winver' make[1]: Leaving directory `/home/viper/d/jgainey/build/WINE/wine-20040716/programs' make[1]: Entering directory `/home/viper/d/jgainey/build/WINE/wine-20040716/server' gcc -c -I. -I. -I../include -I../include -D__WINESRC__ -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o context_i386.o context_i386.c context_i386.c: In function `get_thread_context': context_i386.c:241: `PT_GETREGS' undeclared (first use in this function) context_i386.c:241: (Each undeclared identifier is reported only once context_i386.c:241: for each function it appears in.) context_i386.c:276: `PT_GETFPREGS' undeclared (first use in this function) context_i386.c: In function `set_thread_context': context_i386.c:295: `PT_GETREGS' undeclared (first use in this function) context_i386.c:322: `PT_SETREGS' undeclared (first use in this function) context_i386.c:332: `PT_SETFPREGS' undeclared (first use in this function) make[1]: *** [context_i386.o] Error 1 make[1]: Leaving directory `/home/viper/d/jgainey/build/WINE/wine-20040716/server' make: *** [server] Error 2

1 0

Re: DCOM: Pass -Embedding switch to EXE servers, more tracing
by Jeroen Janssen 26 Jul '04

26 Jul '04

Mike Hearn wrote: > ChangeLog: > Pass -Embedding switch to EXE servers, more tracing > diff -u -p -r1.15 rpc.c > --- dlls/ole32/rpc.c 15 Jul 2004 22:07:44 -0000 1.15 > +++ dlls/ole32/rpc.c 21 Jul 2004 22:43:59 -0000 > @@ -471,8 +471,10 @@ create_server(REFCLSID rclsid) { > char buf[200]; > HRESULT hres = E_UNEXPECTED; > char xclsid[80]; > - WCHAR dllName[MAX_PATH+1]; > - DWORD dllNameLen = sizeof(dllName); > + WCHAR exe[MAX_PATH+1]; > + DWORD exelen = sizeof(exe); > + static const WCHAR embedding[] = { ' ', '-','E','m','b','e','d','d','i','n','g',0 }; > + WCHAR command[MAX_PATH+sizeof(embedding)+1]; On a side note, what exactly is a WCHAR? Is it a 'char' or a 'unicode char' (2bytes)? This in relation to sizeof(embedding) instead of sizeof(embedding)/sizeof(WCHAR)? --- Jeroen

2 1

idl compiler & generating proxy/stub code?
by Jeroen Janssen 26 Jul '04

26 Jul '04

Hi, Is anyone aware of a (free) idl compiler that can also generate proxy/stub code for usage with wine? As far as I understand widl can not generate proxy/stub code (yet). Also, I'm wondering if it would be possible to translate idl to XML and then with XSLT 'transform' into proxy/stub code. --- Jeroen Janssen

1 0

rsabase.dll
by Michael Jung 26 Jul '04

26 Jul '04

Rob, as far as I can tell from looking at your patch, our work is pretty much non overlapping. I worked on the following aspects: - Implementation of "real handles", instead of "address-handles". - Separating OpenSSL dependend code from CSP code. I consider this beneficial, since there seem to be some license issues with OpenSSL (at least for the ReactOS project - there was a short discussion on this on the wine-devel list). If the OpenSSL code is cleanly separated, it will be easier to support GNUTLS or something later. - Basically, my code doesn't do any crypto stuff at all until now (Besides some first lines of code for MD5 hashing). I tried to get the MSDN CryptoAPI examples to compile and run, which only acquire contexts, hash data, derive keys, query CSP params and so on, but which never verify the results. So my code is mainly skin (but elephant skin), no guts. I've attached the current version of my patch. Do you have a certain application, which you want to get running? Would it be ok for you if we proceed as follows: I will wait until you submit your patch (It would be nice if you could add some unit-tests that test for behaviour you depend on). After this you give me a week or two to incorporate my work. Is there any area in rsabase, which you definitely will not implement in the near future and which I could work on until you submit your patch? Greetings, Michael

2 2

Re: WineHQ:service.cgi: fix winrash option
by Ferenc Wagner 26 Jul '04

26 Jul '04

<chmorgan(a)charter.net> writes: > What is the service doing with winrash options btw? The > installer stops, installs and starts the winrash service. > > The installer uses /S for silent installs, otherwise it > will try to popup windows. Are you sure the service isn't > calling the installer with /S? You are right, I was wrong. This patch is rubbish. I can't really understand the errors on wine-test-results. Have you got an idea what may have gone wrong? Aren't any functional winrash instances running? Is something broken in the service script? The documentation is somewhat scarce so I'm doing a slow start... -- Feri.

1 0

problems with lxr setup at winehq?
by Jeroen Janssen 26 Jul '04

26 Jul '04

Hi, I'm trying to use the lxr setup for wine at winehq, but it doesn't seem to work correctly (or I'm doing something wrong). I'm looking for all sourcefiles containing "ClassFactory", following this link: http://source.winehq.org/search?string=ClassFactory . The result I am getting is 'empty'. Does anyone with access to the lxr setup know what the problem is? (and maybe fix it?) --- Jeroen

1 0

Re: Scrollbars, an application bug or a wine regression ? (#2314)
by Dmitry Timoshkov 26 Jul '04

26 Jul '04

"George Marshall" <g.marshall(a)nospam.com> wrote: > > Does reverting of the following patch help? > > Yes it does make the application work as it did before > the June Release :-) Do you have a small application I could test with? -- Dmitry.

4 16

Re: add autodetect audio driver capability to winmm
by Marcus Meissner 26 Jul '04

26 Jul '04

On Sun, Jul 25, 2004 at 05:08:04PM -0500, James Hawkins wrote: > Changelog: > * take audio autodetection out of winecfg and put it in winmm > * if driver is not found in the registry or the driver fails to > load, then autodetect driver This would make artsd the default driver on KDE systems. Most are still using the OSS driver, which might be of a better state. Ciao, Marcus

1 0

Re: add autodetect audio driver capability to winmm
by Robert Shearman 26 Jul '04

26 Jul '04

James Hawkins wrote: >Changelog: > * take audio autodetection out of winecfg and put it in winmm > * if driver is not found in the registry or the driver fails to >load, then autodetect driver > > Thanks for another cool patch. It lessens the burden on the user. CC'ing ros-kernel as explained below. >Index: dlls/winmm/lolvldrv.c >=================================================================== >RCS file: /home/wine/wine/dlls/winmm/lolvldrv.c,v >retrieving revision 1.58 >diff -u -r1.58 lolvldrv.c >--- dlls/winmm/lolvldrv.c 1 Jun 2004 19:40:48 -0000 1.58 >+++ dlls/winmm/lolvldrv.c 25 Jul 2004 22:05:54 -0000 >@@ -30,6 +30,8 @@ > #include "winver.h" > #include "winemm.h" > #include "wine/debug.h" >+#include "config.h" >+#include "wine/port.h" > > WINE_DEFAULT_DEBUG_CHANNEL(winmm); > >@@ -711,6 +713,80 @@ > } > > /************************************************************************** >+ * MMDRV_AutoDetectDriver [internal] >+ * >+ * modified from programs/winecfg/audio.c >+ */ >+BOOL MMDRV_AutoDetectDriver(void) >+{ >+ struct stat buf; >+ const char *argv_new[4]; >+ int fd; >+ >+ char *driversFound[10]; >+ char *name[10]; >+ int numFound = 0; >+ >+ argv_new[0] = "/bin/sh"; > I think the ReactOS people may have a few comments to make on this, now that they are using this DLL in ReactOS. >+ argv_new[1] = "-c"; >+ argv_new[3] = NULL; >+ >+ /* try to detect arts */ >+ argv_new[2] = "ps awx|grep artsd|grep -v grep|grep artsd > /dev/null"; >+ if(!spawnvp(_P_WAIT, "/bin/sh", argv_new)) >+ { >+ driversFound[numFound] = "winearts.drv"; >+ name[numFound] = "aRts"; >+ numFound++; >+ } >+ >+ /* try to detect jack */ >+ argv_new[2] = "ps awx|grep jackd|grep -v grep|grep jackd > /dev/null"; >+ if(!spawnvp(_P_WAIT, "/bin/sh", argv_new)) >+ { >+ driversFound[numFound] = "winejack.drv"; >+ name[numFound] = "jack"; >+ numFound++; >+ } >+ >+ /* try to detect nas */ >+ /* TODO */ >+ >+ /* try to detect audioIO (solaris) */ >+ /* TODO */ >+ >+ /* try to detect alsa */ >+ if(!stat("/proc/asound", &buf)) >+ { >+ driversFound[numFound] = "winealsa.drv"; >+ name[numFound] = "Alsa"; >+ numFound++; >+ } >+ >+ /* try to detect oss */ >+ fd = open("/dev/dsp", O_WRONLY | O_NONBLOCK); >+ if(fd) >+ { >+ close(fd); >+ driversFound[numFound] = "wineoss.drv"; >+ name[numFound] = "OSS"; >+ numFound++; >+ } >+ >+ >+ if (numFound == 0) >+ { >+ TRACE("Could not detect any audio devices/servers"); >+ return FALSE; >+ } >+ >+ /* TODO: possibly smarter handling of multiple drivers? */ >+ TRACE("Found driver %s\n", name[0]); >+ >+ return MMDRV_Install(driversFound[0], driversFound[0], FALSE); >+} >+ >+/************************************************************************** > * MMDRV_InitFromRegistry [internal] > */ > static BOOL MMDRV_InitFromRegistry(void) >@@ -729,7 +805,9 @@ > } > > size = sizeof(buffer); >- if (!RegQueryValueExA(hKey, "Drivers", 0, &type, (LPVOID)buffer, &size)) { >+ BOOL keyQueried = !RegQueryValueExA(hKey, "Drivers", 0, &type, >+ (LPVOID)buffer, &size); > This is only available in C99. We try to make Wine compile with as many C compilers as possible, including gcc 2.95, which doesn't allow this sort of thing. >+ if (keyQueried) { > p1 = buffer; > while (p1) { > p2 = strchr(p1, ';'); >@@ -738,7 +816,11 @@ > p1 = p2; > } > } >- >+ >+ /* if no driver specified in reg or driver fails to load then autodetect */ >+ if (!keyQueried || !ret) >+ ret |= MMDRV_AutoDetectDriver(); >+ > /* finish with mappers */ > size = sizeof(buffer); > if (!RegQueryValueExA(hKey, "WaveMapper", 0, &type, (LPVOID)buffer, &size)) > > Rob

4 6

Support for Palm USB Hotsync
by Harald Milz 25 Jul '04

25 Jul '04

Hi, I am new to this list (albeit not to Wine :-) my Wine usage dates back to 1993 when I interviewed Bob Amstadt in his home... ) Anyway - I have a problem with Palm USB hotsync which could perhaps be solved on the userspace level. As you all know, the Linux USB kernel code creates an in-kernel device (in this case, ttyUSB1) only when a connected device actually talks. With a Palm, this is only the case if one presses the hotsync button. This keeps me from running Hotsync permanently which I need to sync my Palm against Lotus Notes. As soon as I start Hotsync, it complains that the device is not there at all. Even if I press "hotsync" and start Hotsync immediately after that, no communication takes place. (pilot-xfer -p /dev/ttyUSB1 works just fine) Now, for Wine / Cxoffice, ttyUSB is merely a serial device. Wouldn't it be possible to modify the Wine code in a way to fake the open() call and return success to the caller, poll the actual device and open it as soon as it actually comes up? I would be willing to hack this in but I have no real idea where to look regarding the sheer size of the code. I suspect it's in server/serial.c but I am not sure. Any hint is welcome. Or does somebody have an idea how to work around this problem? Until recently, I used a serial hotsync cable but my new notebook has no serial port any more... and carrying an USBserial converter isn't really an option on the road. (IrDA could be an alternative but I couldn't get this to work with my T41 either, at least not with FIR). -- Try to be the best of whatever you are, even if what you are is no good.

2 1

winecfg todo list
by Mike Hearn 25 Jul '04

25 Jul '04

So, I talked with Chris and here are some tasks remaining on winecfg. All of these are *easy* and can be done by anybody who has basic coding ability. For a few of them you don't even really need to know C! So come on lurkers, I know you're out there, step on up. Things that need to be done before we should switch to winecfg IMHO are: * Windows Look has no associated edit control. Who modifies this setting these days anyway? I vote for killing the label rather than adding the edit. * UseTakeFocus (FIXME) - why is this a setting in the UI? I don't even know what the UseTakeFocus protocol does, I've certainly never tweaked it. Does it need to be there? At the very least it needs to be rephrased into terms people can understand and the FIXME needs to be removed. * In the Drives tab, the top half is full of widgetry we probably don't want anymore. In particular "Use real windows drive" etc doesn't make much sense, you can just change the c: mapping to get that effect and it's not something we want to encourage anyway. Especially as most people these days seem to use XP rather than Win98 using a real windows drive is fast way to get an inoperable Wine as well as (possibly) a torched Windows install if it's on FAT32 and you can even pick up viruses from them. I kid you not, the other day I ran a program that had been sitting on my Windows XP partition for a few months and my virtual windows drive (I think the term virtual rather than fake sounds better) ended up infected with some W32.Bagle variant. Anyway the top half of this tab doesn't do anything, never did, doesn't make any sense and should just be removed. * We should probably merge the X11 Driver and Audio tabs together as they both have lots of empty space, and rename it to "Audio and Video" or something. I think the term "X11 Driver" doesn't make much sense to many people anyway. Minor cosmetic fix: remove the groupbox on the "about" tab, it doesn't provide any information at all. We also may want to stick the authors list in there, as it's a bit more visible than in the shell32 about box which is hardly ever shown. But obviously these things should not block us switching to it. Once those things are done we can apply the patch to switch Wine to using the registry entirely. Is it worth writing a migration tool? I'm not really sure, I guess some people would like their settings preserved but most of the settings people tweak are just check boxes in the new UI anyway and would take like 5 seconds to restore. AppDefaults are a bigger issue but do many people have lots of these? Oh, final thing, we need to double check that removing the config doesn't regress things. I've been running with no config file for a few months now and while there are a few minor things I don't think they are critical. I may well have missed things though. thanks -mike

2 2

Invalid path L"c:\\WINDOWS" for L"windows" directory: does not exist
by Andreas Davour 25 Jul '04

25 Jul '04

Hi! I try to use wine v.20040505 on FreeBSD5.2 and I just get the error in the subject line. I found another post about this and that OP was just told to check the "dosdevices" directly, since I have such a directory and I don't get any closer to a solution by staring uncomprehending at the files I thought maybe someone could give a wine newbie some more ideas on what to do? I didn't find any "C:" in that directory mentioned, and tried to make a c: synlink to a new directory without any more success. /andreas

3 3

Marshalling tutorial
by Mike Hearn 25 Jul '04

25 Jul '04

Hi guys, Here is the start of some notes on DCOM and OLE RPC. They're intended to help people like Duane who are hitting problems caused by it, and possibly to form the basis of some decent documentation for the developer guide. Things that only a few people understand make me nervous, getting this stuff into writing will maybe help increase the number of people working on Wine - at the very least it means when people move on we're not left stranded. Firstly, even though this is a reasonably high level overview it's not exactly bed time reading. DCOM is massively complex, and tends to abuse and duplicate terminology rampantly. If you read this and get confused or don't understand it DON'T PANIC! That's perfectly normal. I'll use the term "DCOM" to refer to all aspects of COM and OLE marshalling though other terms could certainly be used too. DCOM is a huge, sprawling part of the Windows API and it's impossible to cover it all in one email. If people find this helpful maybe I'll write some more. I'll assume a basic knowledge of COM (interfaces, IUnknown, refcounts etc). The basics are well documented and there are plenty of tutorials on the net. Secondly, my understanding is not 100% complete and is still improving. There may well be mistakes and omissions here. Hopefully Ove, Marcus, Huw or somebody with a better understanding than I, will review it and correct me. BASICS The basic idea behind DCOM is to take a COM object and make it location transparent. That means you can use it from other threads, processes and machines without having to worry about the fact that you can't just dereference the interface vtable pointer to call methods on it. You might be wondering about putting threads next to processes and machines in that last paragraph. You can access thread safe objects from multiple threads without DCOM normally, right? Why would you need RPC magic to do that? Well, the details of why you'd want to do that can be left until later. For now, suffice it to say that COM lets you "marshal" interfaces into other "apartments". An apartment (you may see it referred to as a context in modern versions of COM) can be thought of as a location, and contains objects. Every thread in a program that uses COM exists in an apartment. If a thread wishes to use an object from another apartment, marshalling and the whole DCOM infrastructure gets involved to make that happen behind the scenes. So. Each COM object resides in an apartment, and each apartment resides in a process, and each process resides in a machine, and each machine resides in a network. Allowing those objects to be used from *any* of these different places is what DCOM is all about. The process of marshalling refers to taking a function call in an apartment and actually performing it in another apartment. Let's say you have two machines, A and B, and on machine B there is an object sitting in a DLL on the hard disk. You want to create an instance of that object (activate it) and use it as if you had compiled it into your own program. This is hard, because the remote object is expecting to be called by code in its own address space - it may do things like accept pointers to linked lists and even return other objects. Very basic marshalling is easy enough to understand. You take a method on a remote interface, copy each of its parameters into a buffer, and send it to the remote computer. On the other end, the remote server reads each parameter from the buffer, calls the method, writes the result into another buffer and sends it back. The tricky part is exactly how to encode those parameters in the buffer, and how to convert standard stdcall/cdecl method calls to network packets and back again. This is the job of the RPCRT4.DLL file - or the Remote Procedure Call Runtime. The backbone of DCOM is this RPC runtime, which is an implementation of DCE RPC [1]. DCE RPC is not naturally object oriented, so this protocol is extended with some new constructs and by assigning new meanings to some of the packet fields, to produce ORPC or Object RPC. You might see it called MS-RPC as well. RPC packets contain a buffer containing marshalled data in NDR format. NDR is short for "Network Data Representation" and is similar the XDR format used in SunRPC (the closest native equivalent on Linux to DCE RPC). NDR/XDR are all based on the idea of graph serialization and were worked out during the 80s, meaning they are very powerful and can do things like marshal doubly linked lists and other rather tricky structures. In Wine, our DCOM implementation is *not* based on the RPC runtime, as while few programs use DCOM even fewer use RPC directly so it was developed some time after OLE32/OLEAUT32 were. Eventually this will have to be fixed, otherwise our DCOM will never be compatible with Microsofts. Bear this in mind as you read through the code however. PROXIES AND STUBS Manually marshalling and unmarshalling each method call using the NDR APIs (NdrConformantArrayMarshall etc) is very tedious work, so the Platform SDK ships with a tool called "midl" which is an IDL compiler. IDL or the "Interface Definition Language" is a tool designed specifically for describing interfaces in a reasonably language neutral fashion, though in reality it bears a close resemblence to C++. By describing the functions you want to expose via RPC in IDL therefore, it becomes possible to pass this file to MIDL which spits out a huge amount of C source code. That code defines functions which have the same prototype as the functions described in your IDL but which internally take each argument, marshal it using Ndr, send the packet, and unmarshal the return. Because this code proxies the code from the client to the server, the functions are called proxies. Easy, right? Of course, in the RPC server process at the other end, you need some way to unmarshal the RPCs, so you have functions also generated by MIDL which are the inverse of the proxies: they accept an NDR buffer, extract the parameters, call the real function then marshal the result back. They are called stubs, and stand in for the real calling code in the client process. The sort of marshalling/unmarshalling code that MIDL spits out can be seen in dlls/oleaut32/oaidl_p.c - it's not exactly what it would look like as that file contains DCOM proxies/stubs which are different, but you get the idea. Proxy functions take the arguments and feel them to the NDR marshallers (or picklers), invoke an NdrProxySendReceive and then convert the out parameters and return code. There's a ton of goop in there for dealing with buffer allocation, exceptions and so on - it's really ugly code. But, this is the basic concept behind DCE RPC. INTERFACE MARSHALLING Standard NDR only knows about C style function calls - they can accept and even return structures, but it has no concept of COM interfaces. Confusingly DCE RPC *does* have a concept of RPC interfaces which are just convenient ways to bundle function calls together into namespaces, but let's ignore that for now as it just muddies the water. The primary extension made by Microsoft to NDR then was the ability to take a COM interface pointer and marshal that into the NDR stream. The basic theory of proxies and stubs and IDL is still here, but it's been modified slightly. Whereas before you could define a bunch of functions in IDL, now a new "object" keyword has appeared. This tells MIDL that you're describing a COM interface, and as a result the proxies/stubs it generates are also COM objects. That's a very important distinction. When you make a call to a remote COM object you do it via a proxy object that COM has constructed on the fly. Likewise, a stub object on the remote end unpacks the RPC packet and makes the call. Because this is object-oriented RPC, there are a few complications: for instance, a call that goes via the same proxies/stubs may end up at a different object instance, so the RPC runtime keeps track of "this" and "that" in the RPC packets. This leads naturally onto the question of how we got those proxy/stub objects in the first place, and where they came from. You can use the CoCreateInstanceEx API to activate COM objects on a remote machine, this works like CoCreateInstance API. Behind the scenes, a lot of stuff is involved to do this (like IRemoteActivation, IOXIDResolver and so on) but let's gloss over that for now. When DCOM creates an object on a remote machine, the DCOM runtime on that machine activates the object in the usual way (by looking it up in the registry etc) and then marshals the requested interface back to the client. Marshalling an interface takes a pointer, and produces a buffer containing all the information DCOM needs to construct a proxy object in the client, a stub object in the server and link the two together. The structure of a marshalled interface pointer is somewhat complex. Let's ignore that too. The important thing is how COM proxies/stubs are loaded. COM PROXY/STUB SYSTEM COM proxies are objects that implement both the interfaces needing to be proxied and also IRpcProxyBuffer. Likewise, COM stubs implement IRpcStubBuffer and understand how to invoke the methods of the requested interface. You may be wondering what the word "buffer" is doing in those interface names. I'm not sure either, except that a running theme in DCOM is that interfaces which have nothing to do with buffers have the word Buffer appended to them, seemingly at random. Ignore it and *don't let it confuse you* :) This stuff is convoluted enough ... The IRpc[Proxy/Stub]Buffer interfaces are used to control the proxy/stub objects and are one of the many semi-public interfaces used in DCOM. DCOM is theoretically an internet RFC [2] and is specced out, but in reality the only implementation of it apart from ours is Microsofts, and as a result there are lots of interfaces which *can* be used if you want to customize or control DCOM but in practice are badly documented or not documented at all, or exist mostly as interfaces between MIDL generated code and COM itself. Don't pay too much attention to the MSDN definitions of these interfaces and APIs. COM proxies and stubs are like any other normal COM object - they are registered in the registry, they can be loaded with CoCreateInstance and so on. They have to be in process (in DLLs) however. They aren't activated directly by COM however, instead the process goes something like this: - COM receives a marshalled interface packet, and retrieves the IID of the marshalled interface from it - COM looks in HKEY_CLASSES_ROOT/Interface/{whatever-iid}/ProxyStubClsId32 to retrieve the CLSID of another COM object, which implements IPSFactoryBuffer. - IPSFactoryBuffer has only two methods, CreateProxy and CreateStub. COM calls whichever is appropriate: CreateStub for the server, CreateProxy for the client. MIDL will normally provide an implementation of this object for you in the code it generates. Once CreateProxy has been called, the resultant object is QId to IRpcProxyBuffer, which only has 1 method, IRpcProxyBuffer::Connect [4] This method only takes one parameter, the IRpcChannelBuffer object which encapsulates the "RPC Channel" between the client and server. On the server side, a similar process is performed - the PSFactoryBuffer is created, CreateStub is called, result is QId to IRpcStubBuffer, and IRpcStubBuffer::Connect is used to link it to the RPC channel. RPC CHANNELS Remember the RPC runtime? Well, that's not just responsible for marshalling stuff, it also controls the connection and protocols between the client and server. We can ignore the details of this for now, suffice it to say that an RPC Channel is a COM object that implements IRpcChannelBuffer, and it's basically an abstraction of different RPC methods. For instance, in the case of inter-thread marshalling (not covered here) the RPC connection code isn't used, only the NDR marshallers are, so IRpcChannelBuffer in that case isn't actually implemented by RPCRT4 but rather just by the COM/OLE DLLS (fixme: is this actually correct?). RPC channels are constructed on the fly by DCOM as part of the marshalling process. So, when you make a call on a COM proxy, it goes like this: Your code -> COM proxy object -> RPC Channel -> COM stub object -> Their code HOW THIS ACTUALLY WORKS IN WINE Right now, Wine does not use the NDR marshallers or RPC to implement its DCOM. When you marshal an interface in Wine, in the server process a _StubMgrThread thread is started. I haven't gone into the stub manager here. The important thing is that eventually a _StubReaderThread is started which accepts marshalled DCOM RPCs, and then passes them to IRpcStubBuffer::Invoke on the correct stub object which in turn demarshals the packet and performs the call. The threads started by our implementation of DCOM are never terminated, they just hang around until the process dies. Remember that I said our DCOM doesn't use RPC? Well, you might be thinking "but we use IRpcStubBuffer like we're supposed to ... isn't that provided by MIDL which generates code that uses the NDR APIs?". If so pat yourself on the back, you're still with me. Go get a cup of coffee. TYPELIB MARSHALLER In fact, the reason for the PSFactoryBuffer layer of indirection is because you not all interfaces are marshalled using MIDL generated code. Why not? Well, to understand *that* you have to see that one of the driving forces behind OLE and by extension DCOM was the development Visual Basic. Microsoft wanted VB developers to be first class citizens in the COM world, but things like writing IDL and compiling them with a C compiler into DLLs wasn't easy enough. So, type libraries were invented. Actually they were invented as part of a parallel line of COM development known as "OLE Automation", but let's not get into that here. Type libraries are basically binary IDL files, except that despite there being two type library formats neither of them can fully express everything expressable in IDL. Anyway, with a type library (which can be embedded as a resource into a DLL) you have another option beyond compiling MIDL output - you can set the ProxyStubClsId32 registry entry for your interfaces to the CLSID of the "type library marshaller" or "universal marshaller". Both terms are used, but in the Wine source it's called the typelib marshaller. The type library marshaller constructs proxy and stub objects on the fly. It does so by having generic marshalling glue which reads the information from the type libraries, and takes the parameters directly off the stack. The CreateProxy method actually builds a vtable out of blocks of assembly stitched together which pass control to _xCall, which then does the marshalling. You can see all this magic in dlls/oleaut32/tmarshal.c In the case of InstallShield, it actually comes with typelibs for all the interfaces it needs to marshal (fixme: is this right?), but they actually use a mix of MIDL and typelib marshalling. In order to cover up for the fact that we don't really use RPC they're all force to go via the typelib marshaller - that's what the 1 || hack is for and what the "Registering non-automation type library!" warning is about (I think). WRAPUP OK, so there are some (very) basic notes on DCOM. There's a ton of stuff I have not covered: - Format strings/MOPs - Apartments, threading models, inter-thread marshalling - OXIDs/OIDs, etc, IOXIDResolver - IRemoteActivation - Complex/simple pings, distributed garbage collection - Marshalling IDispatch - Structure of marshalled interface pointers (STDOBJREFs etc) - Runtime class object registration (CoRegisterClassObject), ROT - IRemUnknown - Exactly how InstallShield uses DCOM Then there's a bunch of stuff I still don't understand, like ICallFrame, interface pointer swizzling, exactly where and how all this stuff is actually implemented and so on. But for now that's enough. thanks -mike FURTHER READING Most of these documents assume you have knowledge only contained in other documents. You may have to reread them a few times for it all to make sense. Don't feel you need to read these to understand DCOM, you don't, you only need to look at them if you're planning to help implement it. [1] http://www.opengroup.org/onlinepubs/009629399/toc.htm [2] http://www.grimes.demon.co.uk/DCOM/DCOMSpec.htm [3] http://msdn.microsoft.com/library/default.asp?url=/library/en-us/com/htm/cm… [4] http://msdn.microsoft.com/library/default.asp?url=/library/en-us/com/htm/cm… http://www.microsoft.com/msj/0398/dcom.aspx http://www.microsoft.com/ntserver/techresources/appserv/COM/DCOM/4_Connecti… http://www.idevresource.com/com/library/articles/comonlinux.asp (unfortunately part 2 of this article does not seem to exist anymore, if it was ever written)

5 8

Re: Is bugzilla worth keeping?
by Ivan Leo Puoti 25 Jul '04

25 Jul '04

> 2. The people entering bugs aren't always developers and don't always > have the skills to provide a good bug report. We have a tools for writing bug report, tools/bug_report.pl We should encourage people to use it to write bug reports. Also closing unmaintained bugs would be a good idea. Ivan.

1 0

Re: rsabase unit tests
by Michael Jung 25 Jul '04

25 Jul '04

Am Sonntag, 25. Juli 2004 13:56 schrieben Sie: > Michael Jung wrote: > >Greetings, > >Michael > > > >Changelog: > > Added unit tests for CPGenRandom API function of rsabase.dll > > You seem to be working on Crypto stuff, so I thought I'd better tell you > that I've got a patch pending that implements half of the functionality > in rsabase. > > Rob Thanks for the information. Indeed I've been working on rsabase.dll. When do you plan to submit your patch? I would like to see if at least some of my code can be incorporated, or if the work was in vain. Michael

1 0

location of mouse, scroll wheel handling
by James Hawkins 25 Jul '04

25 Jul '04

Does anyone know where most of the mouse and scroll wheel actions are being handled in the code? For example, say I am surfing the internet with Internet Explorere and WINE and I use my scroll wheel to move the page up and down. Where is the code that handles that? If anyone has any ideas whatsoever (or even if you can just say you don't know) I would really appreciate it. -- James Hawkins

2 1

Re: Support PBS_MARQUE for progress bars
by Thomas Weidenmueller 25 Jul '04

25 Jul '04

Sorry, this patch should compile. Index: dlls/comctl32/progress.c =================================================================== RCS file: /home/wine/wine/dlls/comctl32/progress.c,v retrieving revision 1.36 diff -u -r1.36 progress.c --- dlls/comctl32/progress.c 11 Mar 2004 00:39:53 -0000 1.36 +++ dlls/comctl32/progress.c 25 Jul 2004 12:26:33 -0000 @@ -26,9 +26,6 @@ * Unless otherwise noted, we believe this code to be complete, as per * the specification mentioned above. * If you discover missing features, or bugs, please note them below. - * - * TODO - * --support PBS_MARQUE * */ @@ -59,7 +56,9 @@ /* Control configuration constants */ -#define LED_GAP 2 +#define LED_GAP 2 +#define MARQUEE_LEDS 5 +#define ID_MARQUEE_TIMER 1 /*********************************************************************** * PROGRESS_Invalidate @@ -156,51 +155,215 @@ { if (dwStyle & PBS_VERTICAL) { - INT old_top = rect.top; - rect.top = rightBar; - FillRect(hdc, &rect, hbrBar); - rect.bottom = rect.top; - rect.top = old_top; - FillRect(hdc, &rect, hbrBk); + if (dwStyle & PBS_MARQUEE) + { + INT old_top, old_bottom; + old_top = rect.top; + old_bottom = rect.bottom; + + leds = rect.bottom - rect.top; + ledMStart = (infoPtr->MarqueePos + MARQUEE_LEDS) - leds; + + if(ledMStart > 0) + { + rect.top = max(rect.bottom - ledMStart, old_top); + FillRect(hdc, &rect, hbrBar); + rect.bottom = rect.top; + } + if(infoPtr->MarqueePos > 0) + { + rect.top = max(old_bottom - infoPtr->MarqueePos, old_top); + FillRect(hdc, &rect, hbrBk); + rect.bottom = rect.top; + } + if(rect.top >= old_top) + { + rect.top = max(rect.bottom - MARQUEE_LEDS, old_top); + FillRect(hdc, &rect, hbrBar); + rect.bottom = rect.top; + } + if(rect.top >= old_top) + { + rect.top = old_top; + FillRect(hdc, &rect, hbrBk); + } + } + else + { + INT old_top = rect.top; + rect.top = rightBar; + FillRect(hdc, &rect, hbrBar); + rect.bottom = rect.top; + rect.top = old_top; + FillRect(hdc, &rect, hbrBk); + } } else { - INT old_right = rect.right; - rect.right = rightBar; - FillRect(hdc, &rect, hbrBar); - rect.left = rect.right; - rect.right = old_right; - FillRect(hdc, &rect, hbrBk); + if (dwStyle & PBS_MARQUEE) + { + INT old_left, old_right; + old_left = rect.left; + old_right = rect.right; + + leds = rect.right - rect.left; + ledMStart = (infoPtr->MarqueePos + MARQUEE_LEDS) - leds; + rect.right = rect.left; + + if(ledMStart > 0) + { + rect.right = min(rect.left + ledMStart, old_right); + FillRect(hdc, &rect, hbrBar); + rect.left = rect.right; + } + if(infoPtr->MarqueePos > 0) + { + rect.right = min(old_left + infoPtr->MarqueePos, old_right); + FillRect(hdc, &rect, hbrBk); + rect.left = rect.right; + } + if(rect.right < old_right) + { + rect.right = min(rect.left + MARQUEE_LEDS, old_right); + FillRect(hdc, &rect, hbrBar); + rect.left = rect.right; + } + if(rect.right < old_right) + { + rect.right = old_right; + FillRect(hdc, &rect, hbrBk); + } + } + else + { + INT old_right = rect.right; + rect.right = rightBar; + FillRect(hdc, &rect, hbrBar); + rect.left = rect.right; + rect.right = old_right; + FillRect(hdc, &rect, hbrBk); + } } } else { if (dwStyle & PBS_VERTICAL) { - while(rect.bottom > rightBar) { - rect.top = rect.bottom - ledWidth; - if (rect.top < rightMost) - rect.top = rightMost; - FillRect(hdc, &rect, hbrBar); - rect.bottom = rect.top; - rect.top -= LED_GAP; - if (rect.top <= rightBar) break; - FillRect(hdc, &rect, hbrBk); - rect.bottom = rect.top; + if (dwStyle & PBS_MARQUEE) + { + INT i, old_top, old_bottom; + old_top = rect.top; + old_bottom = rect.bottom; + + leds = ((rect.bottom - rect.top) + (ledWidth + LED_GAP) - 1) / (ledWidth + LED_GAP); + ledMStart = (infoPtr->MarqueePos + MARQUEE_LEDS) - leds; + + while(ledMStart > 0) + { + rect.top = max(rect.bottom - ledWidth, old_top); + FillRect(hdc, &rect, hbrBar); + rect.bottom = rect.top; + rect.top -= LED_GAP; + if (rect.top <= old_top) break; + FillRect(hdc, &rect, hbrBk); + rect.bottom = rect.top; + ledMStart--; + } + if(infoPtr->MarqueePos > 0) + { + rect.top = max(old_bottom - (infoPtr->MarqueePos * (ledWidth + LED_GAP)), old_top); + FillRect(hdc, &rect, hbrBk); + rect.bottom = rect.top; + } + for(i = 0; i < MARQUEE_LEDS && rect.top >= old_top; i++) + { + rect.top = max(rect.bottom - ledWidth, old_top); + FillRect(hdc, &rect, hbrBar); + rect.bottom = rect.top; + rect.top -= LED_GAP; + if (rect.top <= old_top) break; + FillRect(hdc, &rect, hbrBk); + rect.bottom = rect.top; + } + if(rect.top >= old_top) + { + rect.top = old_top; + FillRect(hdc, &rect, hbrBk); + } + } + else + { + while(rect.bottom > rightBar) { + rect.top = rect.bottom - ledWidth; + if (rect.top < rightMost) + rect.top = rightMost; + FillRect(hdc, &rect, hbrBar); + rect.bottom = rect.top; + rect.top -= LED_GAP; + if (rect.top <= rightBar) break; + FillRect(hdc, &rect, hbrBk); + rect.bottom = rect.top; + } } rect.top = rightMost; FillRect(hdc, &rect, hbrBk); } else { - while(rect.left < rightBar) { - rect.right = rect.left + ledWidth; - if (rect.right > rightMost) - rect.right = rightMost; - FillRect(hdc, &rect, hbrBar); - rect.left = rect.right; - rect.right += LED_GAP; - if (rect.right >= rightBar) break; + if (dwStyle & PBS_MARQUEE) + { + INT i, old_right, old_left; + old_left = rect.left; + old_right = rect.right; + + leds = ((rect.right - rect.left) + ledWidth - 1) / (ledWidth + LED_GAP); + ledMStart = (infoPtr->MarqueePos + MARQUEE_LEDS) - leds; + rect.right = rect.left; + + while(ledMStart > 0) + { + rect.right = min(rect.left + ledWidth, old_right); + FillRect(hdc, &rect, hbrBar); + rect.left = rect.right; + rect.right += LED_GAP; + if (rect.right > old_right) break; + FillRect(hdc, &rect, hbrBk); + rect.left = rect.right; + ledMStart--; + } + if(infoPtr->MarqueePos > 0) + { + rect.right = min(old_left + (infoPtr->MarqueePos * (ledWidth + LED_GAP)), old_right); + FillRect(hdc, &rect, hbrBk); + rect.left = rect.right; + } + for(i = 0; i < MARQUEE_LEDS && rect.right < old_right; i++) + { + rect.right = min(rect.left + ledWidth, old_right); + FillRect(hdc, &rect, hbrBar); + rect.left = rect.right; + rect.right += LED_GAP; + if (rect.right > old_right) break; + FillRect(hdc, &rect, hbrBk); + rect.left = rect.right; + } + if(rect.right < old_right) + { + rect.right = old_right; + FillRect(hdc, &rect, hbrBk); + } + } + else + { + while(rect.left < rightBar) { + rect.right = rect.left + ledWidth; + if (rect.right > rightMost) + rect.right = rightMost; + FillRect(hdc, &rect, hbrBar); + rect.left = rect.right; + rect.right += LED_GAP; + if (rect.right >= rightBar) break; + FillRect(hdc, &rect, hbrBk); + rect.left = rect.right; + } + rect.right = rightMost; FillRect(hdc, &rect, hbrBk); - rect.left = rect.right; } - rect.right = rightMost; - FillRect(hdc, &rect, hbrBk); } } @@ -229,6 +392,63 @@ /*********************************************************************** + * PROGRESS_Timer + * Handle the marquee timer messages + */ +static LRESULT PROGRESS_Timer (PROGRESS_INFO *infoPtr, INT idTimer) +{ + if(idTimer == ID_MARQUEE_TIMER) + { + LONG style = GetWindowLongW (infoPtr->Self, GWL_STYLE); + RECT rect; + int ledWidth, leds; + + GetClientRect (infoPtr->Self, &rect); + InflateRect(&rect, -1, -1); + + if(!(style & PBS_SMOOTH)) + { + int width, height; + + if(style & PBS_VERTICAL) + { + width = rect.bottom - rect.top; + height = rect.right - rect.left; + } + else + { + height = rect.bottom - rect.top; + width = rect.right - rect.left; + } + ledWidth = MulDiv (height, 2, 3); + leds = (width + ledWidth - 1) / (ledWidth + LED_GAP); + } + else + { + ledWidth = 1; + if(style & PBS_VERTICAL) + { + leds = rect.bottom - rect.top; + } + else + { + leds = rect.right - rect.left; + } + } + + /* increment the marquee progress */ + if(++infoPtr->MarqueePos >= leds) + { + infoPtr->MarqueePos = 0; + } + + InvalidateRect(infoPtr->Self, &rect, TRUE); + } + return 0; +} + + +/*********************************************************************** * PROGRESS_CoercePos * Makes sure the current position (CurVal) is within bounds. */ @@ -304,6 +524,8 @@ infoPtr->MaxVal = 100; infoPtr->CurVal = 0; infoPtr->Step = 10; + infoPtr->MarqueePos = 0; + infoPtr->Marquee = FALSE; infoPtr->ColorBar = CLR_DEFAULT; infoPtr->ColorBk = CLR_DEFAULT; infoPtr->Font = 0; @@ -326,6 +548,9 @@ case WM_PAINT: return PROGRESS_Paint (infoPtr, (HDC)wParam); + case WM_TIMER: + return PROGRESS_Timer (infoPtr, (INT)wParam); + case PBM_DELTAPOS: { INT oldVal; @@ -400,6 +625,19 @@ infoPtr->ColorBk = (COLORREF)lParam; InvalidateRect(hwnd, NULL, TRUE); return 0; + + case PBM_SETMARQUEE: + if(wParam != 0) + { + infoPtr->Marquee = TRUE; + SetTimer(infoPtr->Self, ID_MARQUEE_TIMER, (UINT)lParam, NULL); + } + else + { + infoPtr->Marquee = FALSE; + KillTimer(infoPtr->Self, ID_MARQUEE_TIMER); + } + return infoPtr->Marquee; default: if ((message >= WM_USER) && (message < WM_APP)) Index: include/commctrl.h =================================================================== RCS file: /home/wine/wine/include/commctrl.h,v retrieving revision 1.134 diff -u -r1.134 commctrl.h --- include/commctrl.h 6 Jul 2004 21:02:36 -0000 1.134 +++ include/commctrl.h 25 Jul 2004 12:13:28 -0000 @@ -456,10 +456,12 @@ #define PBM_GETRANGE (WM_USER+7) #define PBM_GETPOS (WM_USER+8) #define PBM_SETBARCOLOR (WM_USER+9) +#define PBM_SETMARQUEE (WM_USER+10) #define PBM_SETBKCOLOR CCM_SETBKCOLOR #define PBS_SMOOTH 0x01 #define PBS_VERTICAL 0x04 +#define PBS_MARQUEE 0x08 typedef struct {

1 0

how can I find what functions a dll file provides?
by James Hawkins 25 Jul '04

25 Jul '04

In what way can I list the API functions provided from a certain dll file? I seem to remember seeing somewhere that you could use a debugger, but I'm not sure. -- James Hawkins

4 3

Re: Implement StdMarshal::ReleaseMarshalData
by Jeroen Janssen 25 Jul '04

25 Jul '04

Mike Hearn wrote: > Mike Hearn <mh(a)codeweavers.com> > Rob Shearman <rob(a)codeweavers.com> > Implement StdMarshal::ReleaseMarshalData > + res = IRpcStubBuffer_Release(stub); I'm not sure but, is there a hypothical race condition here when a thread switch takes place and someone tries to reuse the stub while valid is not set to TRUE yet (but the stub has already been released)? > + stubs[i].valid = FALSE; --- Jeroen Janssen

3 4

(Quite) Slow Starcraft
by Maurizio Monge 25 Jul '04

25 Jul '04

It is now really *slow*, but a quite old 2d game such as starcraft that runs perfectly in a PII 300 under windows should also run perfectly on linux with an AMD64 3200 :-) It happens that using the nasty DGA hack on sourceforge.net/projects/starcraft-wine applied by hand to current cvs it does run (as root) perfectly. but even if X11 is a sucky architecture for games it should run perfectly too with accelerated X11+XShm. Instead it happens that *sometimes* it runs fast (as with DGA), and sometimes it becomes unacceptably slow (for little time, though). I started to give a look at wine source to understand why this strange thing happens, but i fould no place where DGA and X11 code paths could differ in this way... maybe with x11 there are such things as an additionl wine thread or boh... maybe you wine hackers are already aware of similar problems, or may help me to understand what's up (and i would like possibly to help fix it). Thanx Please CC monge(at)sns(dot)it as i'm not subscribed. -- Best Regards Maurizio Monge "..the triumph of evil is for good men to do nothing." (Edmond Burke)

1 0

status of advapi32
by James Hawkins 25 Jul '04

25 Jul '04

Hi all, Using Dependency Walker to extract the function names from the advapi32.dll, I have compiled a list of implemented, stubbed, semi-stubbed, missing, and questionable api functions of advapi32.dll. As for the percentage that is completed, using implemented / total * 100, advapi32.dll is 50% complete. With this format, developers can see what has already been done and what has yet to be done. It puts the whole process into a proper perspective. If anyone has any ideas about this or suggestions, let me know. -- James Hawkins

1 0

Re: Is bugzilla worth keeping?
by Ivan Leo Puoti 24 Jul '04

24 Jul '04

Of course we should keep it. It's a place to track bugs, and keep everything related to a non working application in the same place. And if we didn't have it, people would just flood the devel list with bug reports, or not report at all, and non of them seem a great idea. I've got a couple bugs fixed with bugzilla, and if wine will ever be finished then eventually all the bugs will be fixed. And not really we get messages on the patches list with patches that fix something in bugzilla. And it's a good place to send developers that aren't sure what to do next. Ivan.

3 2

out of sync (MSDN) web references in the wine code
by Jeroen Janssen 24 Jul '04

24 Jul '04

Hello, I'm wondering.. it seems there are a lot (MSDN) web references throughout the code. However, some of those links are out of date. Either the pages do not exist anymore, or moved to somewhere else. Is there any structural way to handle this? I mean, I want to look something up on the web based upon an url in the code, but the page doesn't exist anymore. So I could send in a patch to either remove the link, or find a correct one. But what is stopping (MSDN) people from moving things to a different location again, breaking the link again? --- Jeroen Janssen

2 1

Re: slightly OT: c expression evaluation order
by Diego 'Flameeyes' Pettenò 24 Jul '04

24 Jul '04

Michael Jung wrote: > I've always thought that the order in which subexpressions are evaluated > is not specified in the C language. Isn't there the danger of a NULL > pointer dereference given here? I don't think so. Order is expressed and is from left to right, so if you have two functions and do func1() && func2() if func1() will be evalutated as false, func2() will never be called. I saw code wrote without if statements and using directly the logic operators (also if I don't like this syntax) and also Gentoo's scripts (ebuilds and init.d) uses this syntax for some conditional statements. So it should be sure that there won't be a null pointer deference. Regards, -- Diego "Flameeyes" Pettenò dgp85(a)users.sourceforge.net - http://flameeyes.web.ctonet.it/

1 0

slightly OT: c expression evaluation order
by Michael Jung 24 Jul '04

24 Jul '04

Hello, this is slightly of topic for this mailing list. However, it would be nice if someone could answer my question. I've seen that Alexandre changed the if statement expression in one of my patches from if (pszProvider ? *pszProvider == '\0' : 1) to if (!pszProvider || !*pszProvider) I've always thought that the order in which subexpressions are evaluated is not specified in the C language. Isn't there the danger of a NULL pointer dereference given here? Thanks, Michael

2 1

dlls/winmm/wineoss/audio.c build failure
by Gerald Pfeifer 24 Jul '04

24 Jul '04

The following change to dlls/winmm/wineoss/audio.c revision 1.135 date: 2004/07/19 20:08:06; author: julliard; state: Exp; lines: +1 -1 Francois Gouget <fgouget(a)codeweavers.com> Use round() instead of ceil() in wodGetPosition(TIME_SMPTE). Fixes the corresponding winmm conformance test. causes the following build failure on FreeBSD 4.9: ../../../tools/winegcc/winegcc -B../../../tools/winebuild -shared ./wineoss.drv.spec audio.o midi.o midipatch.o mixer.o mmaux.o oss.o wineoss.drv.dbg.o -o wineoss.drv.so -L../../../dlls -lwinmm -luser32 -lkernel32 -L../../../libs/wine -lwine -ldxguid -luuid -L../../../libs/port -lwine_port audio.o: In function `wodGetPosition': /test/wine/dlls/winmm/wineoss/audio.c:2127: undefined reference to `round' collect2: ld returned 1 exit status winegcc: /sw/gcc-3.3.2/bin/gcc failed. gmake: *** [wineoss.drv.so] Error 2 Gerald -- Gerald Pfeifer (Jerry) gerald(a)pfeifer.com http://www.pfeifer.com/gerald/

2 2

Re: wine/dlls/kernel locale.c
by Dmitry Timoshkov 24 Jul '04

24 Jul '04

"Alexandre Julliard" <julliard(a)winehq.org> wrote: > Log message: > Shachar Shemesh <wine-patches(a)shemesh.biz> > System default locale in Windows determines the ANSI encoding > (LC_CTYPE on Unix). I still think that this patch is wrong. On my english win2k with locale set to russian both GetSystemDefaultLCID and GetUserDefaultLCID return 0419. -- Dmitry.

1 0

Division by zero in snd_pcm_rate_sw_params()
by Francois Gouget 24 Jul '04

24 Jul '04

Hi, I am working on Wine and lately I have been tracking various sound related issues. One issue I noticed is a crash in Wine's winmm wave test when using the Alsa sound backend. More precisely: * if Wine's winmm wave test is the only application using the sound device, then it works * but if another application is already using the sound device (e.g. xmms), then Wine's winmm wave test crashes when trying to play the 96kHz test. The crash occurs when calling snd_pcm_sw_params(): EXIT_ON_ERROR( snd_pcm_sw_params(pcm, sw_params), MMSYSERR_ERROR, "unable to set sw params for playback"); See this URL for the exact source: http://source.winehq.org/source/dlls/winmm/winealsa/audio.c#L1602 Digging some more I found out that the division by zero happens in the snd_pcm_rate_sw_params() function pcm_rate.c. Here's why: * Wine sets xfer_align to 1: EXIT_ON_ERROR(snd_pcm_sw_params_set_xfer_align(pcm, sw_params, 1), MMSYSERR_ERROR, "unable to set xfer align"); * then it calls snd_pcm_sw_params() as shown above * eventually we get to snd_pcm_rate_sw_params() in src/pcm/pcm_rate.c. (http://cvs.sourceforge.net/viewcvs.py/alsa/alsa-lib/src/pcm/pcm_rate.c?rev=…) * There we call recalc(): recalc(pcm, &sparams->xfer_align); * when more than one application uses the soundcard, recalc() ends up doing: *val = muldiv_near(*val, slave->period_size, pcm->period_size); * however in my case slave->period_size is less than half of pcm->period_size so I end up with xfer_align == *val == 0. * then, a few lines later in snd_pcm_rate_sw_params() we do: if (sparams->start_threshold > (slave->buffer_size / sparams->xfer_align) * sparams->xfer_align) sparams->start_threshold = (slave->buffer_size / sparams->xfer_align) * sparams->xfer_align; And we crash with a division by zero because now sparams->xfer_align==0. (these lines were added in CVS revision 1.83 of this file) Simply resetting xfer_align to 1 is it is zero after the call to recalc() (see attached patch) fixes the problem for me (no crash and the test tone plays correctly). However I don't know if this is the right fix, hence the following questions: Does my patch look ok? What is the proper procedure to get it applied? Is there further information I can provide to resolve this issue? My configuration: * Up to date Debian testing * Alsa 1.0.5a * cat /proc/asound/cards 0 [V8235 ]: VIA8233 - VIA 8235 VIA 8235 at 0xbc00, irq 5 -- Francois Gouget fgouget(a)codeweavers.com --- pcm_rate.c.orig 2004-07-24 03:19:41.000000000 +0200 +++ pcm_rate.c 2004-07-24 03:20:41.000000000 +0200 @@ -630,6 +638,8 @@ recalc(pcm, &sparams->avail_min); rate->orig_avail_min = sparams->avail_min; recalc(pcm, &sparams->xfer_align); + if (sparams->xfer_align==0) + sparams->xfer_align=1; recalc(pcm, &sparams->start_threshold); if (sparams->start_threshold <= slave->buffer_size) { if (sparams->start_threshold > (slave->buffer_size / sparams->avail_min) * sparams->avail_min)

1 0

Re: make crosstest fails
by Ivan Leo Puoti 24 Jul '04

24 Jul '04

> Or can we actually use this instead? > http://prdownloads.sourceforge.net/wine/wine-w32api-20040505.zip?download You should be able to use them, or I don't see the point of having them. Note that updated versions exist http://prdownloads.sourceforge.net/wine/wine-w32api-20040615.zip?download http://prdownloads.sourceforge.net/wine/wine-w32api-20040716.zip?download Ivan.

1 0

Re: devenum
by Ivan Leo Puoti 23 Jul '04

23 Jul '04

> Why you do not leave the neutral resources in the main archive? That's how it's done in other files, anyway, I'll send another patch that leaves the neutral resources in the main file. Ivan.

1 0

Re: Install msiexec in the bin dir while make install.
by Alexandre Julliard 23 Jul '04

23 Jul '04

Vincent Béron <vberon(a)mecano.gme.usherb.ca> writes: > Alexandre, what are the guidelines for installing winelib applications > in /foo/bin/? It should be restricted to apps that users will frequently run from the command-line on Windows so that they expect the same behavior on Wine, or else to apps prefixed with 'wine' as there isn't a risk of conflict in that case. I'm not sure msiexec qualifies; is it really something that end users are expected to use on Windows? -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: French translation and other adjustments
by Francois Gouget 23 Jul '04

23 Jul '04

On Fri, 23 Jul 2004, Marcelo Duarte wrote: > Changelog: > Marcelo Duarte <wine-devel(a)bol.com.br> > French translation and other adjustments + IDS_RESTART_TITLE "Recommencer" + IDS_RESTART_PROMPT "Tu voulez simuler la remise du Windows?" + IDS_SHUTDOWN_TITLE "Débrancher" + IDS_SHUTDOWN_PROMPT "Tu voulez finir la session du Wine?" Urgh! Maybe you meant something like: + IDS_RESTART_TITLE "Recommencer" + IDS_RESTART_PROMPT "Voulez-vous simuler le redémarrage de Windows?" + IDS_SHUTDOWN_TITLE "Arrêter" + IDS_SHUTDOWN_PROMPT "Voulez-vous fermer la la session Wine?" Note: I not entirely sure about 'Arrêter'. Translation can be pretty tricky sometimes... -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Before you criticize someone, walk a mile in his shoes. That way, if he gets angry, he'll be a mile away - and barefoot.

2 1

Re: Add a WINEVER environment variable
by Andreas Mohr 23 Jul '04

23 Jul '04

Hi, I'm afraid I don't like the naming, since it's potentially confusing (plus, it somewhat goes against established rules, "WINE + function"). What about WINEWINVER instead? I for one like it much more. Also, this doesn't take into account that we're also able to set the DOS version. So what would that be called then? WINEVER, too? ;-) WINEWINVER and WINEDOSVER is a much better choice, IMHO. Greetings, Andreas

3 4

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel