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

Re: Need some help with a patch for version.dll

by Stefan Dösinger

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

Aug. 25, 2005

Re: Need some help with a patch for version.dll

by Stefan Dösinger

Am Donnerstag, 25. August 2005 13:45 schrieb Paul Vriens: > 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 ? Get a good C book and read about Pointer arithmetics ;-) I haven't applied the patch and looked at the existing code, but from the warnings I can tell that you're doing arithmetic with a pointer which has no type( "void *" ). Assumed, you have a char *Pc and a int *Pi both point to 0x10. If you do "Pc++" and "Pi++" then sizeof(char) and sizeof(int) are added to the pointers, so Pc will point to 0x11 and Pi to 0x14. But what to do with a void * ? sizeof(void) = ???? So you have to give the pointers the compiler complains about a type, most likely you want a char *. Hope I helped, Stefan

Aug. 25, 2005

Re: Compiling winelib dependant code with g++

by Ivan Leo Puoti

Gaudet Michael-MGAU01 wrote: > 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 I don't use winelib much but maybe you have to explicitly link against the needed dlls? Ivan.

Aug. 25, 2005

compile a shared object using winelib with g++

by Gaudet Michael-MGAU01

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.

Aug. 25, 2005

Compiling winelib dependant code with g++

by Gaudet Michael-MGAU01

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.

Aug. 25, 2005

Need some help with a patch for version.dll

by Paul Vriens

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.

Aug. 25, 2005

Re: Bugzilla - old rubbish bugs...

by Ivan Leo Puoti

Ann & Jason Edmeades wrote: > 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! Go for it Ivan.

Aug. 25, 2005

Re: OpenGL windowing and wglMakeCurrent

by Marcus Meissner

On Wed, Aug 24, 2005 at 02:40:48PM -0700, Russ wrote: > Trying to get my 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, and the entire X11 window's redraw is > mangled---OpenGL is affecting the entire X11 Window. > > In Win32, when you call wglMakeCurrent, the opengl context is configured to > match the size/position of the HWND for the HDC, even if it is only a small > child window, 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. It is possible that glScissor might be used. A more accurate > wglMakeCurrent emulation is necessary for a usable port. Suggestions welcome. No need to repeat it ... I have seen the same, but no ideas. ;) Ciao, Marcus

Aug. 25, 2005

Re: Loading resources from wine dlls

by Michael Jung

On Thursday 25 August 2005 09:56, Michael Jung wrote: > Would it be ok to look for an ELF header and then for an enclosed PE header > in USER32_GetResourceTable (and then return IMAGE_NT_SIGNATURE and the > correct pointer)? Where can I find informations about the format of ELF > wrapped PEs? Thinking about it again, there probably is no such thing as an ELF wrapped PE? Bye, -- Michael Jung mjung(a)iss.tu-darmstadt.de

Aug. 25, 2005

Re: FW: [bug 3064] Listbox fails to populate

by Alexandre Julliard

"Ann & Jason Edmeades" <us(a)edmeades.me.uk> writes: > Was there any problem with this one or did it just get missed? LISTBOX_RemoveItem already does pretty much the same check, you should reuse that instead of duplicating it, you just need to remove the -1 special case in there. -- Alexandre Julliard julliard(a)winehq.org

Aug. 25, 2005