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

wglMakeCurrent doesn't pick up HDC region
by Russ 23 Aug '05

23 Aug '05

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 23 Aug '05

23 Aug '05

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 23 Aug '05

23 Aug '05

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 23 Aug '05

23 Aug '05

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 23 Aug '05

23 Aug '05

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 22 Aug '05

22 Aug '05

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 22 Aug '05

22 Aug '05

> 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 22 Aug '05

22 Aug '05

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 22 Aug '05

22 Aug '05

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 22 Aug '05

22 Aug '05

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