wine-devel

wine-devel@winehq.org

4 participants
84464 discussions

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@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@16' string.o(.text+0x1d61):string.c: undefined reference to `wvsnprintfW@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@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

Problem in scheduler/process.c
by Dustin Navea 17 May '02

17 May '02

ok, so I have found the cause of the problem in scheduler/process.c that is making ut-based installers not work. the problem is the code from line 450 to line 461 inclusive. in all programs, PROCESS_InitWine is called from int main in miscemu/main.c, then open_winelib_app is called from PROCESS_InitWine (always) where things go wrong... in a normal program, 1 of 2 things (im not sure which though) happens... 1) line 451 evaluates to false so that section is skipped and then line 461 is also evaluated to false, so it is also skipped, so open_winelib_app returns either null or " " (not sure of the difference) -or- 2) line 451 evaluates to true, and then 457 also evaluates to true, so open_winelib_app returns NULL. with the ut-based installer that is the case, but the Setup.exe that is on the root of the cd acts differently... 1) 451 evaluates to false and then 461 evaluates to true, causing wine to attempt to load the real installer (called by the one in the root of the cd) as a .so, which doesn't work. -or- 2) 451 evaluates to true and 457 evaluates to false, so it goes on to 461, which evaluates to true... with winelib apps the same thing happens as with the "root-of-cd" installer except that the .so file does exist and so it gets loaded... so, i think what needs to be done is a check in PROCESS_InitWine for the kind of binary (windows or winelib). and if it is a winelib binary, then run call open_winelib_app, otherwise proceed with normal loading... probably the easiest way to do this would be like this line 491-494 if (argv[0] != 'wine') { if (open_winelib_app( app_argv )) goto found; } that way you could probably completely remove lines 450-459 which are in open_winelib_app, since all it does is check to make sure argv[0] doesn't equal wine... i would try this method out and submit it, but i won't be back at home until tonight, so i can't make any diff's. if someone wants to give it a go and let us know if it works, please give me credit for the _idea_. hopefully this solves some other problems too... comments appreciated. -Dustin __________________________________________________ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com

1 0

Jump to page:

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