- Wine-devel - list.winehq.org

[Patch] scheduler/process.c
by Dustin Navea 19 May '02

19 May '02

Ok, here is a quick rundown of the problem... all programs were being passed to open_winelib_app by PROCESS_InitWine. Once inside open_winelib_app, there was a sanity check for if argv[0] was equal to wine which if it was and you were trying to run a winelib app, then it would bail out, and if it wasn't it would run the program if it was wine and you weren't trying to run a winelib app then it would run it... the problem was that with /mnt/cdrom/Setup.exe not being the real installer for Unreal Tournament (being just a caller for the real installer), argv[0] would equal wine on the first run though (/mnt/cdrom/Setup.exe), but it would equal /usr/local/bin/wine on the 2nd run through (/mnt/cdrom/System/Setup.exe), which doesn't equal "wine", so it would try to open the app as a winelib app. I moved that incorrect code from open_winelib_app to PROCESS_InitWine and modified it so that it would change "/usr/local/bin/wine" to "wine" but otherwise leave it alone... the code is ugly, but it works, if someone want's to clean it up, feel free to do so, just give me credit for the original submission... -Dustin __________________________________________________ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com Author: Dustin Navea ChangeLog: adds the necessary check to PROCESS_InitWine, so that we no longer pass _every_ application to open_winelib_app (saving some headaches with weird windows binaries) License: ALL Permissions: you may use this to teach yourself c, and may modify the code in this diff, only to clean it up. you must maintain this notice and give credit for the original submission in your cleaned up submission. ===================================================================================== --- scheduler/process.c Sat May 18 20:23:26 2002 +++ scheduler/process.c.new Sat May 18 20:18:55 2002 @@ -447,21 +447,12 @@ } else { - const char *argv0 = main_exe_name; - if (!*argv0) - { - /* if argv[0] is "wine", don't try to load anything */ - argv0 = argv[0]; - if (!(name = strrchr( argv0, '/' ))) name = argv0; - else name++; - if (!strcmp( name, "wine" )) return NULL; - } - /* now try argv[0] with ".so" appended */ if ((tmp = HeapAlloc( GetProcessHeap(), 0, strlen(argv0) + 4 ))) { strcpy( tmp, argv0 ); strcat( tmp, ".so" ); + name = argv0; /* search in PATH only if there was no '/' in argv[0] */ ret = wine_dll_load_main_exe( tmp, (name == argv0), errStr, sizeof(errStr) ); if (!ret && !argv[1]) @@ -485,11 +476,31 @@ void PROCESS_InitWine( int argc, char *argv[], LPSTR win16_exe_name, HANDLE *win16_exe_file ) { DWORD stack_size = 0; + const char *name; /* Initialize everything */ if (!process_init( argv )) exit(1); - if (open_winelib_app( app_argv )) goto found; /* try to open argv[0] as a winelib app */ + /* these next 2 if's check the name of the wine executable being run for + compatibility with weird apps */ + if (!(name = strrchr( argv[0], '/' ))) name = argv[0]; + else + { + name = strrchr( argv[0], '/' ); + name = strstr( name, "wine" ); + } + if (!(argv0 = strrchr( argv[0], '/' ))) argv0 = argv[0]; + else + { + argv0 = strrchr( argv[0], '/' ); + argv0 = strstr( argv0, "wine" ); + } + + if ((strcmp( argv0, "wine" )) && (strcmp( name, "wine" ))) + { + /* try to open argv[0] as a winelib app */ + if (open_winelib_app( app_argv )) goto found; + } app_argv++; /* remove argv[0] (wine itself) */ app_argc--;

1 0

Patch for dinput keyboard
by arjen＠blehq.org 19 May '02

19 May '02

This 'beautiful' patch I wrote for fixing dinput was silently ignored. Can someone comment about it? here is a link to it: http://www.winehq.com/hypermail/wine-patches/2002/05/0047.html Thank you

3 5

Re: Mingw devel stuff Part2
by Steven Edwards 19 May '02

19 May '02

After that patch I am also able to compile these dlls Comcat.dll Crtdll.dll Msisys.ocx Netapi32.dll Riched32.dll Serialui.dll Twain_32.dll Wintrust.dll I know that some of them are mostly stubs but its still a good start. I understand WINEs crtdll just forwards call to msvcrt.dll but will this also work on a Windows Target? I was under the impression this Wouldn't work due to crtdll not being thread safe. Or will this only Work on *NIX hosts using wines MSVCRT? Its not a big deal to the ReactOS project as we already have crtdll and msvcrt we maintain but it would always be nice to have one less thing to keep up. Thanks Steven "Every revolution was once a thought in one man's mind" - Ralph Waldo Emerson

1 0

process.c problem update
by Dustin Navea 18 May '02

18 May '02

Ok, I finally implemented the right checks in process.c to get the Unreal Tournament-based installers working properly, now all I have to do is make the diff and submit it. The code is very ugly and I was wondering if someone would volunteer to clean it up, since I'm not sure if it will be committed in it's current state... Also, will be included a fix for Blizzard Installers that "cant find program start menu". Seems there is a missing registry entry... If you are willing to clean up my messy code, please email me privately and let me know. -Dustin __________________________________________________ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com

1 0

Mingw devel stuff Part2
by Steven Edwards 18 May '02

18 May '02

Sorry about that I hit the send button to soon. OK when I try build shlwapi.dll I'm getting this Administrator(a)LAPTOP /cygdrive/d/src/winehq/wine/dlls/shlwapi $ make dllwrap --add-stdcall-alias --def shlwapi.spec.def --implib shlwapi.a -o shlwapi .dll ordinal.o path.o reg.o regstream.o shlwapi_main.o string.o url.o shlwa pi.dll.dbg.o -L../../dlls -luser32 -lgdi32 -ladvapi32 -lkernel32 -L../../library -lwine -L../../ole -lwine_uuid -L../../unicode -lwine_unicode -lm Warning: resolving ___wine_dbgstr_guid by linking to __imp____wine_dbgstr_guid ( auto-import) Warning: resolving ___wine_dbgstr_an by linking to __imp____wine_dbgstr_an (auto -import) Warning: resolving ___wine_dbgstr_wn by linking to __imp____wine_dbgstr_wn (auto -import) ordinal.o(.text+0x52d6):ordinal.c: undefined reference to `wctype_table' ordinal.o(.text+0x52eb):ordinal.c: undefined reference to `wctype_table' path.o(.text+0x74d6):path.c: undefined reference to `casemap_lower' path.o(.text+0x74eb):path.c: undefined reference to `casemap_lower' path.o(.text+0x751a):path.c: undefined reference to `casemap_upper' path.o(.text+0x752f):path.c: undefined reference to `casemap_upper' path.o(.text+0x7752):path.c: undefined reference to `wctype_table' path.o(.text+0x7767):path.c: undefined reference to `wctype_table' string.o(.text+0x1d2d):string.c: undefined reference to `wvsnprintfA(a)16' string.o(.text+0x1d61):string.c: undefined reference to `wvsnprintfW(a)16' string.o(.text+0x1d8e):string.c: undefined reference to `casemap_upper' string.o(.text+0x1da3):string.c: undefined reference to `casemap_upper' url.o(.text+0x4426):url.c: undefined reference to `wctype_table' url.o(.text+0x443b):url.c: undefined reference to `wctype_table' fu000001.o(.idata$3+0xc): undefined reference to `libwine_a_iname' fu000002.o(.idata$3+0xc): undefined reference to `libwine_a_iname' fu000004.o(.idata$3+0xc): undefined reference to `libwine_a_iname' fu000005.o(.idata$3+0xc): undefined reference to `libwine_a_iname' fu000006.o(.idata$3+0xc): undefined reference to `libwine_a_iname' fu000007.o(.idata$3+0xc): more undefined references to `libwine_a_iname' follow nmth000000.o(.idata$4+0x0): undefined reference to `_nm____wine_dbgstr_guid' nmth000003.o(.idata$4+0x0): undefined reference to `_nm____wine_dbgstr_an' nmth000009.o(.idata$4+0x0): undefined reference to `_nm____wine_dbgstr_wn' collect2: ld returned 1 exit status dllwrap: gcc exited with status 1 make: *** [shlwapi.dll] Error 1 "Every revolution was once a thought in one man's mind" - Ralph Waldo Emerson

2 3

opengl rendering to the wrong window
by Ryan Stallings 18 May '02

18 May '02

Hello, I am trying to get the Neverwinter Nights Model viewer (http://www.bioware.com/games/neverwinter_nights/other_multimedia/model_view…) working under wine. The menus etc of the model viewer come up correctly, but no rendering can be seen in the render window. Through some investigation I determined that the model was being rendered, just in the wrong window. I moved the window out of the way by a few pixels and saw the model was being rendered to what looks like the main window underneath the menu. Here is a screen shot that shows what I mean..... http://nwwine.beergeek.net/shots/nw_offset.jpg The black square is the windows shifted and the blue background is the glClearColor of the rendering window. As you can see the model is under the window :( Now if I move the window way offscreen and add an offset to the glViewport call I can get the model to render in the correct place, but this is obviously not the right solution. What could be causing it to be rendered in the wrong window? The render window has a hwnd =1003e and a drawable client/whole = 0x4000064/0x4000063 and the first couple of time through wglMakeCurrent the drawable that comes back from the hdc that is passed (requested from 1003e) is 0x4000064 which seems right, but I think this is some sort of test renderings offscreen before the application comes up. Later in the logs this is not true. GetDCEx is called with 1003e, but it returns a hdc that has a different drawable associated with it (the one for the root window I think). But even if I try to for the drawable to 0x4000064 is does not render in to the correct window (it does not render at all). Does anybody have any direction to point me in? Or is there any information that I could provide to make the situation more clear? Thanks! ryan

2 1

nasty NTDLL_vsnwprintf bug?!?
by John K. Hohm 18 May '02

18 May '02

My heap corruption problem turned out to be a bug in swprintf (well, really in NTDLL_vsnwprintf), I think. I tried formatting like this: WCHAR keyname[21] = { 'C', 'o', 'm', 'p', 'o', 'n', 'e', 'n', 't', ' ', 'C', 'a', 't', 'e', 'g', 'o', 'r', 'i', 'e', 's', 0 }; WCHAR fmt[4] = { '%', 'l', 'X', 0 }; swprintf(This->xlcid, fmt, lcid); My poor little WCHAR xlcid[9] member of This was seriously overflowed by the string L"409Component Categories". The following patch fixes what appears to be a format reading bug in NTDLL_vsnwprintf. I didn't just send it to wine-patches because it's not my area and it seems unlikely such a bad bug could hang around in such a function. Then again, I don't see many uses of swprintf in the source; should I be using something better for sprintf's of WCHAR's? --- dlls/ntdll/wcstring.c.~1.15.~ Thu May 16 19:59:27 2002 +++ dlls/ntdll/wcstring.c Fri May 17 23:09:21 2002 @@ -451,10 +451,7 @@ } if (*iter == (WCHAR)L'h' || *iter == (WCHAR)L'l') - { *fmta++ = *iter++; - *fmta++ = *iter++; - } switch (*iter) {

1 0

Weird parameters with LVM_GETSUBITEMRECT
by Paul Rupe 17 May '02

17 May '02

A recent change to dlls/comctl32/listview.c implemented GetSubItemRect, but this causes Xnews to hang when selecting a newsgroup from the list. I don't think the change itself is at fault, but it may have uncovered a bug elsewhere. The app gets a message LVM_GETSUBITEMRECT (4152) with the following parameters: wParam: 1078422692 (0x40476ca4) lParam: 1078422612 (0x40476c54) wParam should be a small integer (an index into the listview items) and lParam is a pointer to a RECT: *(LPRECT)lParam: {left = 2, top = 1079544291, right = 28246089, bottom = 1079843718} or {left = 0x2, top = 0x405889e3, right = 0x1af0049, bottom = 0x405d1b86} lParam->left is reasonable, but lParam->top should be a small index. Note that wParam, lParam, and lParam->top are fairly close numerically. The function LISTVIEW_GetSubItemRect then tries to loop from 0 to that huge number, causing the hang. I put a sanity check inside that function to stop it from going past GETITEMCOUNT and that works, but I want to see if I can fix it the right way. -- Paul Rupe "She smiled, in the end." p r u p e @ m y r e a l b o x . c o m | Oppose government police-ware on your PC! | Stop the Consumer Broadband and Digital Television Promotion Act! | <http://www.eff.org/alerts/20020322_eff_cbdtpa_alert.html> --

1 0

Re: fixme:win32:PeekNamedPipe
by Andriy Palamarchuk 17 May '02

17 May '02

I just came across bugzilla entry about this issue - bug 297: http://wine.codeweavers.com/bugs/show_bug.cgi?id=297 If anybody starts to work on the bug, please take this bug and keep it updated. Andriy Palamarchuk __________________________________________________ Do You Yahoo!? Yahoo! Tax Center - online filing with TurboTax http://taxes.yahoo.com/

2 1

Mingw Port Information and Questions
by Steven Edwards 17 May '02

17 May '02

OK so we the latest changes I do need to build libwine.dll right? I can if I link it to msvcrt.a but ig I don't I get the following Administrator(a)LAPTOP /cygdrive/d/src/winehq/wine/library $ make dllwrap --add-stdcall-alias --export-all --implib libwine.a -o libwine.dll debug .o errno.o ldt.o loader.o port.o dllwrap: no export definition file provided dllwrap: creating one, but that may not be what you want debug.o(.text+0x8d4):debug.c: undefined reference to `_imp___iob' loader.o(.text+0x4c4):loader.c: undefined reference to `_assert' loader.o(.text+0x614):loader.c: undefined reference to `_assert' port.o(.text+0x4):port.c: undefined reference to `_errno' port.o(.text+0x30):port.c: undefined reference to `_errno' port.o(.text+0x48):port.c: undefined reference to `_errno' port.o(.text+0x60):port.c: undefined reference to `_errno' port.o(.text+0x78):port.c: undefined reference to `_errno' port.o(.text+0x90):port.c: more undefined references to `_errno' follow collect2: ld returned 1 exit status dllwrap: gcc exited with status 1 make: *** [libwine.dll] Error 1 Also when I try to build shlwapi.dll I get this

1 0