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

More compatible memory arrangement ?: dlls/winsock.c: WS_dup_pe()
by Krzysztof C. Aug. 26, 2005

Aug. 26, 2005

Hi, I was having a problem with a game, it couldn't connect to the server, so I started debugging things, and it ofcourse brought me to dlls/winsock.c but the problem seems to be on the game side ( unfortunately its closed-source, so I can only guess what's happening ). The debugging showed that when the game was getting server's ip from DNS (WS_gethostbyname()), it was getting wrong values. Then I started looking for the cause, and I found out that the game was incorrectly reading the hostent/WS_hostent structure. It was assuming that the ip address was at particular offset from the beginning of the structure, it didn't follow the pointers and thus it was getting wrong data. Then I rewrote few lines of the code and now it looks like: "pointer | pointer | pointer | ... data | data | data | .... " and everything works fine. So I assume that Microsoft's winsock arrange this structure this way, but I am not sure if it is 100% compatible way solving "one application problem", although few other programs dependent on this function worked fine with this change. Anyway I left the topic with question mark because I would like to know someone else's opinion on that. ( btw. I am new to mailing lists and it is my first post, so please don't be too rough on me in your responses : ) Index: dlls/winsock/socket.c =================================================================== RCS file: /home/wine/wine/dlls/winsock/socket.c,v retrieving revision 1.188 diff -u -p -r1.188 socket.c --- dlls/winsock/socket.c 25 Aug 2005 10:22:12 -0000 1.188 +++ dlls/winsock/socket.c 25 Aug 2005 22:20:58 -0000 @@ -3343,16 +3343,16 @@ static struct WS_hostent *WS_dup_he(cons p_to->h_addrtype = p_he->h_addrtype; p_to->h_length = p_he->h_length; - p = (char *)(p_to + 1); + p = (char *)p_to + sizeof(struct hostent); + p_to->h_addr_list = (char **)p; + p += list_dup(p_he->h_addr_list, p_to->h_addr_list, p_he->h_length); + p_to->h_name = p; - strcpy(p, p_he->h_name); - p += strlen(p) + 1; + strcpy(p_to->h_name, p_he->h_name); + p += strlen(p_he->h_name) + 1; p_to->h_aliases = (char **)p; - p += list_dup(p_he->h_aliases, p_to->h_aliases, 0); - - p_to->h_addr_list = (char **)p; - list_dup(p_he->h_addr_list, p_to->h_addr_list, p_he->h_length); + list_dup(p_he->h_aliases, p_to->h_aliases, 0); return p_to; }

1 0

Re: Need some help with a patch for version.dll
by Stefan Dösinger Aug. 25, 2005

Aug. 25, 2005

Hi, > I can't use a LPCSTR, cause: > > BOOL WINAPI VerQueryValueA( LPVOID pBlock, LPCSTR lpSubBlock, > LPVOID *lplpBuffer, UINT *puLen ) > > lplpBuffer points to a place in pBlock where the value is. This value is > in most cases a UNICODE string. This string has to be converted to ANSI > and placed on a different place in pBlock (+ info->wLength + 4). > > Hope this makes sense. Oh, sure, you can't change it here. I guess you need a typecast here to supress the warning. But there are some helper functions for converting a unicode string to an ansi string. If you can use them, this might save you some troubles. Stefan

1 0

Need some help with a patch for version.dll
by Paul Vriens Aug. 25, 2005

Aug. 25, 2005

Hi, I've finally nailed the last (?) bugs in version.dll. The attached patch shows how. There is however a warning during compile and I have no clue (still learning C :-) ) how to fix that: info.c: In function `VerQueryValueA': info.c:754: warning: pointer of type `void *' used in arithmetic info.c:754: warning: pointer of type `void *' used in arithmetic info.c: In function `VerQueryValueW': info.c:817: warning: pointer of type `void *' used in subtraction info.c:817: warning: pointer of type `void *' used in arithmetic Any idea's ? Cheers, Paul.

2 1

Compiling winelib dependant code with g++
by Gaudet Michael-MGAU01 Aug. 25, 2005

Aug. 25, 2005

wineg++ is using g++, and is passing its options to g++. How can I link some winelib-dependant code with g++ ? compilation is okay, but at linking time, all wine functions are unresolved. // ### here's the output :### [root(a)udp015809uds Wine2]# g++ -lwine registry.o registry_wrap.o -o registry.out registry.o(.text+0x2e): In function `CreateKey(char const*)': : undefined reference to `RegCreateKeyA' registry.o(.text+0x58): In function `CreateKey(char const*)': : undefined reference to `RegQueryValueExA' registry.o(.text+0x8f): In function `CreateKey(char const*)': : undefined reference to `RegQueryValueExA' registry.o(.text+0xa5): In function `CreateKey(char const*)': : undefined reference to `MessageBoxA' collect2: ld returned 1 exit status // ### And the same code compiled with wineg++ ### [root(a)udp015809uds Wine2]# wineg++ -lwine registry.o registry_wrap.o -o registry.out // program runs okay. For information, I need to use g++ in order to assimilate wine lib framework to SWIG, to generate Win32 wrappers in C# for mono. Thanks.

2 1

compile a shared object using winelib with g++
by Gaudet Michael-MGAU01 Aug. 25, 2005

Aug. 25, 2005

Hello all. Do you know if there is a way to compile a shared object using winelib with g++ or wineg++ ? I am using wine20050725 under Linux2.6.8.1-12mdk I need references to advapi32.dll and user32.dll. Thanks.

1 0

Bugzilla - old rubbish bugs...
by Ann & Jason Edmeades Aug. 25, 2005

Aug. 25, 2005

I asked this a while ago and noone was too upset, but I am going to try to spend some time slowly closing off some of the bugs which do not have enough info in them to be reproduced, and have not had a response to a request to see if the problem persists for a long time (e.g. 6 months). I wont close anything which is reproducible (I'll try if I can) and I believe if something is wrongfully closed it can always be reopened? If anyone else has a spare moment, feel free to help! At the moment there is >1300 available bugs, but looking at lots of them in detail I doubt there's 500 which are worth keeping! (I was bored and looking for some things to fix and it's like a needle in the haystack looking in bugzilla at the moment). Jason

2 1

Loading resources from wine dlls
by Michael Jung Aug. 25, 2005

Aug. 25, 2005

Hello, I would like to add a 'My Documents' icon to shell32. This icon has a resource ID of 235 in WinXP's shell32. Apparently one can't load resources from wine's own dlls, though. If you call PrivateExtractIcons with 'c:\windows\system32\shell32.dll' as the file name parameter, you'll get a 'WARN: File %s not found or path too long'. I guess that's because there is no such file in wine's fake windows environment. There is a hack (which is even declared as a hack in the comment) in the initialization code of the 'Shell Icon Cache' (starting from line 372 in 'dlls/shell32/iconcache.c'). It loads the first 38 icons from shell32 at initialization time, and later returns them from the cache without having to access the file (which would'nt work). This seems to be a principal problem (Loading resources from wine dlls, if they are accessed by the filename they have on a windows system). Are there any plans on how to fix this? Bye, -- Michael Jung mjung(a)iss.tu-darmstadt.de

3 2

Throwing in an idea (probably it was discussed before though)
by John Smith Aug. 25, 2005

Aug. 25, 2005

As a Win developer, I want to make a suggestion (sorry if it was already discussed - or if similar mechanism already exists): What if some simple way will be provided for Win developers to say which options they prefer for WINE to use for their application? While it may seem to somewhat contradict to the 'big bright future' of the WINE (with all the apps running flawlessly under WINE), it would hopefully allow for immediate increase of out-of-the-box supported applications. For example, it could be a resource string of special format (for example, "__WINE_CONFIG_HINT: "Managed" = "N""), and multiple hints should be allowed. This hint should override system-wide settings but in turn should be overridden by per-app settings in wine config file/registry. _________________________________________________________________ Dont just search. Find. Check out the new MSN Search! http://search.msn.click-url.com/go/onm00200636ave/direct/01/

8 13

Re: secur32: Getting some real functionality into the NTLM provider, try 2
by Juan Lang Aug. 25, 2005

Aug. 25, 2005

Hi Kai, In ntlm.c, + /* convert the program name to Unicode */ (snip) + /* and back to the CP_UNIXCP */ This round-tripping is unnecessary when the text is already ASCII. ASCII values are just as valid in UTF8 as they are in CP1252 or whatever. Basically, don't bother converting anything you can type. + if(pAuthData == NULL) In this if statement, you duplicate the business of converting the user name and domain name to CP_UNIXCP in both branches. You should instead store a pointer to the user name and domain name, and convert them in one common branch after the if statement. + SEC_CHAR *client_argv[] = + { + program, + client_protocol, + client_user_arg, + client_domain_arg, + NULL + }; You must declare variables at the beginning of the block, not in the middle. Not all C compilers allow this. + if(pszPackage != NULL) + { + int package_sizeW = MultiByteToWideChar(CP_ACP, 0, pszPackage, -1, + NULL, 0); Since you don't use pszPackage in ntlm_AcquireCredentialsHandleW, why bother converting it? Just pass NULL. + if(identity->Flags == SEC_WINNT_AUTH_IDENTITY_ANSI) (snip) + else + { + memcpy(pAuthDataW, identity, sizeof(SEC_WINNT_AUTH_IDENTITY_W)); + } This looks funny. Why not just set pAuthDataW to identity in this case? That way you avoid the memcpy. Something like this: PSEC_WINNT_AUTH_IDENTITY_W pAuthDataW; if (identity->Flags == SEC_WINNT_AUTH_IDENTITY_ANSI) { /* convert it like you do */ } else pAuthDataW = (PSEC_WINNT_AUTH_IDENTITY_W)identity; /* call ntlm_AcquireCredentialsHandleW */ if (pAuthDataW != identity) HeapFree(GetProcessHeap(), 0, pAuthDataW); + if((ret = encodeBase64(helper->password, + helper->pwlen-2, buffer+3, + max_len-3, &buffer_len)) != SEC_E_OK) + { + HeapFree(GetProcessHeap(), 0, buffer); + HeapFree(GetProcessHeap(), 0, bin); + return ret; + } You ought to zero the memory of the password and free it, regardless of whether encodeBase64 succeeds or fails. (Really you ought to call SecureZeroMemory, but wine hasn't implemented that.. oh well.) In tests/ntlm.c: + //lstrcpyA(identity->Password, pass ? pass :""); No C++ style comments, please. More generally, on the tests, I like them because they should nearly always succeed in Windows. But they're not very likely to succeed in Wine, are they? You handle not having an ntlm_auth fairly gracefully, I think, and also handle not being able to create an inbound context, which you say may not work without some magic setup. But this won't generally work out of the box if ntlm_auth works and an inbound context can be created, can it? The tests will try to authenticate with whatever domain name is in the registry, or default to WORKGROUP if that's empty, and your UNIX username, and no password. That's not very likely to succeed. So, it would be nice to have these tests somewhere for people to check that this code indeed works.. but I'm not sure they can go into the regression test suite. Unless I'm mistaken. Thanks, --Juan ____________________________________________________ Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs

1 0

Delphi 5 debugger is working!
by Vitaliy Margolen Aug. 24, 2005

Aug. 24, 2005

As of todays CVS Delphi 5 debugger is fixed. Well, ok, there are still some bugs. One is a minor bug (Module view reports all modules as a project executable name), but all exports are there. You can even try to disassemble them. But here is where the major problems start. Debugger segfaults on that. This is because NtQueryVirtualMemory and NtProtectVirtualMemory currently don't work on other processes. I have modified those functions to return STATUS_SUCCESS instead. This allows to access ntdll, kernel32 and possibly any other modules that have the same base address for application and debugger. You might need prelink installed to relocate ntdll and kernel32 to 0x7bxxxxxx addresses. This makes their base addresses the same for all wine apps. Unfortunately fixing NtQueryVirtualMemory, NtProtectVirtualMemory and others is not that simple. Basically there are no way to do it from other processes. Ok, NtQueryVirtualMemory could be implemented some-what easily using NtReadVirtualMemory and possibly one more server call. But for others I see only three ways to implement them: 1. Adding worker thread to each process. This way we can ask it to perform requested operation for us. But, there is a catch - this will complicate lots of things. Besides, messing with processes is not a good thing(tm). It will brake some apps, that don't expect to see more then one thread. Or if we'll try to hide a worker thread, it will make things even worse. 2. Using signal(s). Unfortunately this is not as simple to do ether. From what I been told, this will require non trivial synchronization, that still doesn't guarantee deadlocks. 3. Infamous wine kernel module. Some how I don't think that kernel guys will go for this type of functionality. Even for debugging proposes, it still poses considerable security risk allowing one process manipulate other process' memory. So it will have to be a wine only module, which means we'll have to maintain in against all supported kernel versions and require kernel development environment. Any other solutions that I have forgotten/haven't even thought of? -- Best regards, Vitaliy

5 6

Re: Software patents
by gslink Aug. 24, 2005

Aug. 24, 2005

The whole business of software patents is very likely to explode at any time. There are several software patents on cds and dvds which are so vague that it is impossible to tell exactly what is going on. The licenses to use these patents allow the company issuing the patent to control cd content and to examine it. The first time one of these companies tries to use the license to access DOD classified information there will be a resolution. The easiest way to resolve this business with Borland is to contact Borland. They may also have an interest in Wine. If they have no objection to what Wine wants to do then there is no one else to complain. They might even help Wine. Borland probably doesn't even realize that Wine exists although some of the people in Borland are probably very familiar with it. I think you will find this to be true of all big software companies such as IBM and Microsoft.

8 10

solution for including itss.h in hhctrl.ocx
by James Hawkins Aug. 24, 2005

Aug. 24, 2005

Hey Alexandre, I need to be able to include itss.h from dlls/itss in order to read CHM files. Mike offered the solution that I add -I($SRCDIR)../itss to hhctrl's Makefile.in. The next problem comes when I run make depend. make depend looks for itss.h but can't find it because it hasn't been built yet. Mike then suggested adding ../dlls/itss/itss.idl to IDL_SRCS in include/Makefile.in. That works fine up until make install which gives these two errors: /usr/bin/install: cannot create regular file `/usr/include/wine/windows/../dlls/itss/itss.idl': No such file or directory /usr/bin/install: cannot create regular file `/usr/include/wine/windows/../dlls/itss/itss.h': No such file or directory Do you have any suggestions on how to access itss.h from hhctrl.ocx? -- James Hawkins

2 1

Re: commctrl: dialog theming
by Evil Aug. 24, 2005

Aug. 24, 2005

I'm no longer able to run programs that require the native comctl32 and commctrl DLLs, since updating to today's CVS. Could it be related to these theme patches? It seems that now, if you override comctl32 for any app (or globally), even WineCfg itself will error out with the error. err:thunk:_loadthunk (commctrl.dll, Cctl1632_ThunkData16, comctl32.dll): Unable to load 'commctrl.dll', error 2 err:module:LdrInitializeThunk "comctl32.dll" failed to initialize, aborting err:module:LdrInitializeThunk Main exe initialization for L"c:\\windows\\system32\\winecfg.exe" failed, status c0000142 The native commctrl.dll and comctl32.dll both exist in my windows/system directory - the same versions that always worked before. Overriding commctrl doesn't have any effect on this error. -J Frank Richter wrote: >This patch assumes the listbox patch was applied before. > >Frank Richter <frank.richter(a)gmail.com> >Add theming support for dialogs (to support tab page background). > >

5 9

wine error with 'wine client error:d: write: Bad file descriptor'
by Oliver Mössinger Aug. 24, 2005

Aug. 24, 2005

Hi wine-devel, i have a windows program whitch generates the attached 'wine.txt' wine output. Followed is a part of the output: >>> Threads: process tid prio (all id:s are in hex) 00000042 (D) C:\MGC\LeoSpec\LS2005a_82\bin\win32\leonardo.exe 00000017 0 0000000d 0 <== 0000000e 00000016 0 00000013 0 00000012 0 00000011 0 00000010 0 0000000f 0 WineDbg terminated on pid 0x42 wine client error:d: write: Bad file descriptor <<< The program works with windows! Can someone help me to run the program? thanks Oliver Mössinger

1 0

Re: secur32: Getting real functionality into the NTLM provider
by Alexandre Julliard Aug. 24, 2005

Aug. 24, 2005

Kai Blin <blin(a)gmx.net> writes: > + unsigned char buffer[SECUR32_MAX_BUF_LEN+6000]; > + BYTE bin[SECUR32_MAX_BUF_LEN]; You shouldn't allocate fixed size buffers on the stack, especially not huge ones like that. You should compute the necessary size and allocate a properly sized buffer from the heap. > + SEC_CHAR client_user_arg[512]; > + SEC_CHAR client_domain_arg[512]; > + SEC_CHAR passwd[512] = {0}; Same here, there's nothing that guarantees the buffers are the right size; using snprintf may avoid overflows but it doesn't make the code behave correctly. > +SECURITY_STATUS fork_helperA(PNegoHelperA *new_helper, const char *prog, > + char * const argv[], char* passwd) > +{ You should have a single fork helper that takes Unicode, you can't pass ASCII chars to the Unix app anyway, you have to use CP_UNIXCP. And more generally, you should do everything in Unicode. > + if( ( pipe(pipe_in) < 0 ) || ( pipe(pipe_out) < 0 ) ) > + { > + return SEC_E_INTERNAL_ERROR; > + } > + > + helper->helper_pid = fork(); > + > + helper->password = passwd; > + > + if(helper->helper_pid == -1) > + { > + return SEC_E_INTERNAL_ERROR; > + } You are leaking file descriptors in the error cases. > + if(helper->helper_pid == 0) > + { > + /* We're in the child now */ > + close(0); > + close(1); > + > + dup2(pipe_out[0], 0); > + close(pipe_out[0]); > + close(pipe_out[1]); > + > + dup2(pipe_in[1], 1); > + close(pipe_in[0]); > + close(pipe_in[1]); > + > + execvp(prog, argv); > + > + /* Whoops, we shouldn't get here. Big badaboom.*/ > + return SEC_E_INTERNAL_ERROR; You shouldn't return from the child, you should pass the error back to the parent and then exit(). > + { > + helper->pipe_in = fdopen(pipe_in[0], "r"); > + close(pipe_in[1]); > + helper->pipe_out = fdopen(pipe_out[1], "w"); > + close(pipe_out[0]); > + } You should avoid using stdio. -- Alexandre Julliard julliard(a)winehq.org

2 2

wglMakeCurrent doesn't pick up HDC region
by Russ Aug. 24, 2005

Aug. 24, 2005

Trying to get my commercial 3-D app to run under WINE using the same binary with the odd workaround or two. It uses OpenGL in various subwindows of the main window as needed. Under WINE, the subwindow graphics all get drawn in the lower left corner of the overall X11 window. In Win32, when you call wglMakeCurrent, the opengl context is configured to match the size/position of the HWND for the HDC, so drawing openGL goes just into the desired subwindow. However, the WINE implementation of wglMakeCurrent just calls glXMakeCurrent (and glXCreateContext), which produces the entire size of the X11 window, resulting in the incorrect behavior observed. In my Mac OS X port, I have a similar issue, resolved by calling aglSetInteger(glContext, AGL_BUFFER_RECT,... I'm not sure what a glX equivalent would be to try, I don't see one offhand. As is, emulating the wglMakeCurrent accurately appears impossible, such that apps that use this Windows behavior can not be run. Suggestions welcome. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

1 0

x11drv: use of uninitialized rect
by James Hawkins Aug. 24, 2005

Aug. 24, 2005

Hey, While compiling x11drv, gcc gives the following error: gcc -c -I. -I. -I../../include -I../../include -I/usr/X11R6/include -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o text.o text.c text.c: In function 'X11DRV_ExtTextOut': text.c:85: warning: 'rect.bottom' is used uninitialized in this function text.c:85: warning: 'rect.top' is used uninitialized in this function text.c:85: warning: 'rect.right' is used uninitialized in this function text.c:85: warning: 'rect.left' is used uninitialized in this function Looking through the CVS log for text.c, I saw that before the latest patch, rect would be initialized if lprect == NULL; otherwise, rect = *lprect. My guess is that we want to use lprect instead of rect, but I'm not familiar enough with that code to make the change. Can you take a look at this Huw? Thanks, James Hawkins

1 0

WineHQ will be offline tomorrow
by Jeremy Newman Aug. 23, 2005

Aug. 23, 2005

I will be taking the website offline tomorrow starting at 09:00 CDT (04:00 GMT). I will be moving it to a new ISP. Expect downtime to last for up to 8 hours as I will also be doing a complete reinstall of the OS. This will also affect the mailing lists and the CVS. -- Jeremy Newman <jnewman(a)codeweavers.com> CodeWeavers, Inc.

3 6

Re: winecfg: theming
by Kevin Koltzau Aug. 23, 2005

Aug. 23, 2005

On Tuesday 23 August 2005 2:39 pm, Frank Richter wrote: > + static const WCHAR themesSubdir[] = > + { > '\\','R','e','s','o','u','r','c','e','s','\\','T','h','e','m','e','s',0 }; > + WCHAR themesPath[MAX_PATH]; > + > + free_theme_files(); > + themeFiles = DSA_Create (sizeof (ThemeFile), 1); > + > + GetWindowsDirectoryW (themesPath, MAX_PATH); This should be based on SHGetFolderPath(CSIDL_RESOURCES)

1 0

Re: shell32: Some tests for FolderShortcut class (3rd try)
by Michael Jung Aug. 23, 2005

Aug. 23, 2005

Hi Alexandre, On Monday 22 August 2005 17:04, Michael Jung wrote: > Changelog: > Added some tests for CLSID_FolderShortcut objects Are there any further problems with this patch? Bye, -- Michael Jung mjung(a)iss.tu-darmstadt.de

1 0

Automatic ANSI<>Unicode message translation
by Phil Krylov Aug. 23, 2005

Aug. 23, 2005

Hi, I am having a problem with an app of mine. It posts WM_CHAR messages to a ANSI window with Unicode value in LOWORD(wParam). Wine automatically translates the character code to ANSI (producing a "?" when there is no such code in CP_ACP). Windows does not do it (contrary to documentation). Here is attached (source and binary) a quick and dirty sample application which shows the problem. I could remove map_wparam_AtoW() and map_wparam_WtoA() from dlls/user/message.c, but probably somebody needs that translation. Does anybody have an idea of a better fix for that bug? -- Ph.

5 29

Re: Remove unnecessary #pragma code_page(xxxx) statements from winefile .rc files
by Martin Fuchs Aug. 23, 2005

Aug. 23, 2005

> This is because 'LANGUAGE LANG_xxxx' statements don't actually change > code page specified by a previous '#pragma code_page(xxxx)', therefore > russian resources get translated to unicode using wrong code page. > I don't know whether it's an rc bug or a feature. We either need > to remove '#pragma code_page' statements altogether, or add them > to all included .rc files. I took the 1st approach. > Changelog: > Dmitry Timoshkov <dmitry(a)codeweavers.com> > Remove unnecessary #pragma code_page(xxxx) statements from > winefile .rc files, they confuse the resource compiler. Please be carefull to remove the code page pragmas. IMHO this is not the correct way. When there is no other code page given, the resource compiler uses the current code page of the operating system. And I don't think, all of those language specific resource scripts will compile correct on all possible OS code pages. The reliable way would be to include the correct code page at the begin of all resource scripts. Please take in mind: Wine is compiled on many different environments: LANG_C, de_DE.ISO-8859-1, en_EN.UTF-8, swedish, or whatever... Removing the code page pragmas would require to test the correctness of the compilation results of all different languages on all possible platforms. Regards, Martin

2 1

Safedisc1 CD checks work, it tries to start the game but fails to do so
by Ivan Leo Puoti Aug. 23, 2005

Aug. 23, 2005

Hello list, here's a little update Safedisc1 now successfully passes all anti debugger check, and recognises the CD correctly. It then attempts to start the game, but this doesn't work yet because of the nested exception on signal stack bug. Hopefully we aren't too far from getting it to run. Ivan.

4 3

Re: [winedbg] Don't ever pass a NONCONTINUABLE exception
by Alexandre Julliard Aug. 22, 2005

Aug. 22, 2005

Glenn Wurster <gwurster(a)scs.carleton.ca> writes: > Changelog: > Don't pass on non-continuable exceptions. Why do you want to do that? -- Alexandre Julliard julliard(a)winehq.org

3 6

Re: Throwing in an idea (probably it was discussed before though)
by Jacek Caban Aug. 22, 2005

Aug. 22, 2005

John Smith wrote: >> You can also set it yourselves in in your app. As configuration >> is in registry, every app can modify it. > > > I like this idea, thanks. There are still 2 issues with such a soultion: > a) most likely, it won't work until 2nd start of the application (we > will modify it on the first run, and it most likely won't be applied > until the second run); If you have an installer, you may configure Wine during installation. If not - just detect Wine at the beginning of the app and, if you have to configure Wine, do so and restart the app. It's a bit (very) hackish but it should work and it's not visible for user. > b) current WINE guides are discouraging us from detecting WINE - and > messing up with Windows Registry, especially HKEY_LOCAL_MACHINE, on > all the millions of non-WINE machines is not a thing I would really > like to do (the last thing we want is to be caught by some antivirus, > which monitors activity it considers suspicious and changing > HKEY_LOCAL_MACHINE can easily qualify). > You don't have to touch HKEY_LOCAL_MACHINE, Wine's configuration is in HKEY_CURRENT_USER. And you may use modified WGA (and millions of other) way to detect Wine:-) Note: I still think fixing Wine is better way to go. Jacek

1 0