July 2001 - Wine-Devel - list.winehq.org

Problems running WINE with Half-Life with CounterStrike

by David Bronaugh

Hey all, I'm having some interesting issues with Half-Life running under WINE... I'm guessing these are due to it running under WINE (they are strange enough). #1 problem: I can't type normally in the Half-Life console (the keyboard is mapped to a completely nonsensical map). I believe this is because they implemented their own custom key handler. Is there any workaround in software/with config for this? Note that this is only in the game when the game engine is initialized, otherwise the keyboard works great (Kudos to the WINE people that my dvorak-mapped QWERTY keyboard works as it should in dvorak). #2 problem: I can't get to the Half-Life console without going through some convolutions... This in itself is useless to tell you people. How I do get into the game is by the following method: I join a game or whatever, and the "Loading" screen pops up. At this point.. it will sit there for hours (I'm guessing this is a locking issue with pthreads?). What I do that appears to relieve the deadlock is to click the "Done" button that is invisible (but I know where it is, so I click it). Then the game loads normally, and runs decently enough (performance isn't great, but playable... huge kudos to the Wine crew for that). Note that the only button that does this is the "Done" button, the rest do nothing out of the ordinary. Again, this may be due to some peculiarity with Half-Life or with my config.. I'm betting on a peculiarity with Half-Life interacting with some unimplemented feauture or bug in WINE. If anyone has suggestions re these two, send em to me.. I'm more than happy to spend a few hours to help resolve this. David Bronaugh

July 8, 2001

Are these the ordinal names?

by Peter Hunnisett

Howdy, I have a couple of questions about the following error messages err:win32:fixup_imports No implementation for SHLWAPI.dll.281(wvnsprintfA) imported from C:\windows\system\shdocvw.dll, setting to 0xdeadbeef err:win32:fixup_imports No implementation for SHLWAPI.dll.282(wvnsprintfW) imported from C:\windows\system\shdocvw.dll, setting to 0xdeadbeef err:win32:fixup_imports No implementation for SHLWAPI.dll.240(StrRetToStrW) imported from C:\windows\system\shdocvw.dll, setting to 0xdeadbeef 1) Do these messages mean that 281 is named wvnsprintfA and so on? If so, why does the SHLWAPI.240 name not seem to jive with the existing implementation? 2) Why would I be getting the error for SHLWAPI.dll.240(StrRetToStrW) given the fact that the shlwapi.spec file contains the following line and there does seem to be an implementation in ordinal.c? 240 stdcall @(long long long long) SHLWAPI_240 Ciao, Peter Hunnisett hunnise(a)yahoo.com _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com

July 8, 2001

Re: Win16 problems

by Gerard Patel

At 10:43 PM 03/07/2001 +0200, you wrote: <snip> >winmine fails to draw, whereas freecell runs just fine Yes, I see the problem with winmine; but is it really a 16-bits problem ? What I see is an app creating its main window iconic (minimized), then showing it using ShowWindow. Current Wine code does not take this particular behaviour (completely absurd, granted) in account - When the window is created the 'client' window is not mapped (since it's iconic, nothing surprising here), but in ShowWindow the iconic flag (WS_MINIMIZED) is cleared, and when SetWindowPos is called by ShowWindow, X11DRV_sync_client_window_position cleverly detects that the window is already mapped ;-) and decides that it's not necessary to do anything more. This seems more a Winmine specific problem than otherwise. BTW, I can't see any problem with sol.exe (win3.11 version) This patch : --- window.c.orig Wed Jun 27 03:03:36 2001 +++ window.c Sat Jul 7 23:19:03 2001 @@ -596,7 +596,7 @@ if (was_mapped && !is_client_window_mapped( win )) XUnmapWindow( display, data->client_window ); XConfigureWindow( display, data->client_window, mask, &changes ); - if (!was_mapped && is_client_window_mapped( win )) + if (is_client_window_mapped( win )) XMapWindow( display, data->client_window ); wine_tsx11_unlock(); } works around this particular problem. Gerard

July 7, 2001

Windows .lnk file parsing

by J. Henning Schwentner

Hi Wine developers, I am planning to write a little tool "lnk2desktop" which converts Windows LNK links into KDE/Gnome .desktop links, which you could use then to integrate your Windows start menu into your K menu. When I searched through the wine news archive I found a message about library that parses .lnk files and returns the command to execute, the icon etc. My question is now, does such a library exist and what other ways do exist for finding out such infomations? Regards, Henning Schwentner Lanthan Software KG P.S.: Please CC me, since I am not subscribed to the list.

July 7, 2001

sharing windows between processes

by Bill Medland

Some time ago I raised the issue of the fact that windows handles cannot be shared between processes on the same server and was told that it was a known significant issue. Is anyone doing anything about it? It seems to me that what has to be done is to have wineserver coordinate the allocation of handles. Any comments? Bill

July 6, 2001

Re: Confusing SHGetFolderPath

by Juergen Schmied

The MSDN tells you: ----------- Remarks This function is a superset of {HYPERLINK "SHGetSpecialFolderPath.htm"}SHGetSpecialFolderPath, included with earlier versions of the Shell. It is implemented in a redistributable DLL, SHFolder.dll, that also simulates many of the new Shell folders on older platforms such as Windows 95, Windows 98, and Windows NT 4.0. This DLL always calls the current platform's version of this function. If that fails, it will try to simulate the appropriate behavior. -------- So the shfolder.dll is only for updating older operating systems. WinME/W2K has this function in shell32. The shfolder one has a smaller set of supported CSIDL's. I suspect (by looking on the imports with depends) the shfolder.dll just loads shell32 with LoadLibrary and forwards the functions if a GetProcAddress() is successful. Ciao Juergen From: nog <nog(a)sdf.lonestar.org> Subject: Confusing SHGetFolderPath To: "wine-devel(a)winehq.com" <wine-devel(a)winehq.com> Send reply to: "wine-devel(a)winehq.com" <wine-devel(a)winehq.com> Date sent: Mon, 01 Jul 2002 22:12:13 +0200 > Hi, > > While I was looking through some of the wine dlls' code I found that the > function SHGetFolderPath is in the shell32 dll and the shfolder dll. Is > this ment to be like this? Because the docs that I read says that the > function is meant to be in shfolder. Anyway are the two functions meant > to do the same thing? If so then why is the one in shell32 implemented > and working and the one on shfolder doesn't eaven appear to give a fixme > message? > > Nog > > > >

July 6, 2001

Re: Help with nonclient Windows 95 frame

by Bill Medland

Bill Medland <medbi01(a)accpac.com> wrote in article <01c1058a$50e51260$6f0c10ac(a)medbi01>... > I'd appreciate some advice here before I mess things up for everyone else. > > In the longer term I am fixing a border issue with the edit control, but > before doing so I am fixing up the nonclient frame drawing code (i.e. > NC_DoNCPaint95). > > The code contains quite a bit of calculation based upon the system metrics. > The code seems to reflect the Windows documentation. However it should > come as no surprise that there are disagreements between that documentation > and what I see on my Win95 computer! For example a frame with WS_THICKEDGE > but no WS_BORDER nor WS_DLGFRAME nor WS_EX_DLGMODALFRAME on my computer is > only 3 pixels wide, not 4 (although one of those pixels is the COLOR_WINDOW > associated with the WS_THICKEDGE) > > Is there a way to adjust the size of the borders on the Win95 to be able to > see what affects what? > > Bill > > > > > yes. Control Panel->Display->Appearance->Item and mess about (e.g. adjusting ActiveWindowBorder adjusts the BorderWidth setting in the WindowMetrics section of the Registry)

July 6, 2001

Help with nonclient Windows 95 frame

by Bill Medland

I'd appreciate some advice here before I mess things up for everyone else. In the longer term I am fixing a border issue with the edit control, but before doing so I am fixing up the nonclient frame drawing code (i.e. NC_DoNCPaint95). The code contains quite a bit of calculation based upon the system metrics. The code seems to reflect the Windows documentation. However it should come as no surprise that there are disagreements between that documentation and what I see on my Win95 computer! For example a frame with WS_THICKEDGE but no WS_BORDER nor WS_DLGFRAME nor WS_EX_DLGMODALFRAME on my computer is only 3 pixels wide, not 4 (although one of those pixels is the COLOR_WINDOW associated with the WS_THICKEDGE) Is there a way to adjust the size of the borders on the Win95 to be able to see what affects what? Bill

July 5, 2001

Mouse events

by Duane Clark

Howdy, Just tried the most recent CVS. I found that the patch from 6/25 to windows/x11drv/event.c has led to mildly annoying mouse behavior in certain (admittedly very limited) cases. Here is the change that did it: @@ -292,21 +291,8 @@ case ButtonRelease: EVENT_ButtonRelease( hWnd, (XButtonEvent*)event ); break; case MotionNotify: - /* Wine between two fast machines across the overloaded campus - ethernet gets very boged down in MotionEvents. The following - simply finds the last motion event in the queue and drops - the rest. On a good link events are servered before they build - up so this doesn't take place. On a slow link this may cause - problems if the event order is important. I'm not yet seen - of any problems. Jon 7/6/96. - */ - if ((current_input_type == X11DRV_INPUT_ABSOLUTE) && - (in_transition == FALSE)) - /* Only cumulate events if in absolute mode */ - while (TSXCheckTypedWindowEvent(display,((XAnyEvent *)event)->;window, - MotionNotify, event)); EVENT_MotionNotify( hWnd, (XMotionEvent*)event ); break; I assume some problem led to its removal. I regularly try out Myst (the 32 bit version) as a test, running locally on a 700MHz Athlon, so this can't be blamed on a slow ethernet connection or slow machine. When dragging the slide controls in the "planetarium", they used to follow the mouse just fine. With this patch, if you grab the control, move the mouse and release it, the control does not keep up with the mouse but just moves at a moderately slow pace until it reaches the point where the mouse was released (a few seconds to travel from one end to the other). At that point everything returns to normal. Other similar slide controls, such as the musical slide controls in the space ship, work fine with the patch, however. Perhaps it is possible that the code above was masking some other problem causing the control to move too slowly to follow the mouse? Duane

July 3, 2001

Re: Win16 problems

by Ove Kaaven

On Tue, 3 Jul 2001, eric pouech wrote: > > I could probably look into the OpenGL problem if that was the only > > problem, but why are Win16 windows never drawn anyway? > > (Unfortunately, I don't have sol.exe here, I tested with MS Word > > Viewer 16-bit, but DOS apps like Monkey Island gets the same issues in my > > tree) > well; same issue here (without opengl support) > however, it's not consistent across all apps > winmine fails to draw, whereas freecell runs just fine I thought FreeCell was a Win32 app (it was part of the Win32s package for Win3.x).

July 3, 2001