March 2006 - Wine-Devel - list.winehq.org

Re: May be a bad idea to have Winetools in the next SUSE release

by Jan Z.

Thank you, Andreas Jaeger for the clarification regarding the inclusion of Winetools in SUSE. On Thu, Mar 09, 2006 at 02:27:23PM +0100, Joachim von Thadden wrote: > Am Thu, Mar 09, 2006 at 01:41:06PM +0100 schrieb Jan Zerebecki: > > Winetools is only sporadically updated for new versions of Wine > > (as http://www.von-thadden.de/Joachim/WineTools/ indicates; this > > site also contains some warnings regarding the support status). > > WineTools is not "sporadically" updated as it makes no sense to update > it with every new Wine release. The purpose is not to keep track Wine, > the purpose is to have a stable basis. As such WineTools often stays > with a specific Wine version for a time. This is the same what > Crossover-Office does. So you would also not include that if you were > allowed to? Sorry, I wasn't aware of that. Perhaps then the best for Winetools users and Wine developers is to enable Winetools to be distributed with it's own version of Wine (as cx-office and cedega do it) and (as someone else already suggested) to save it's data and fake Windows under .winetools . That would also prevent problems when a distribution contains a version of Wine that is not supposed to be used with the contained version of Winetools. For example afaik the SUSE factory tree contains Wine 0.9.5 and Winetools 0.9jo but your website suggests Wine 0.9.{1,2,3} for that Winetools version. What do you think about this? > > Winetools radically alters some vital Wine settings and thus > > makes many other apps fail. > > This first part is true, the second definitely not. WineTools is at the > moment the only way to have all major commercial windows programs run > simultaneously with Wine under Linux if you do not want to pay for > Crossover-Office. I think you forgot that one can manually configure wine to support that, even if it is a bit of work. > If what you say is true then name the apps that fail with WineTools and > run with *plain* Wine. I am waiting for your list. And I will include > them in the next release (if I can download them legaly). >From various users i got the impression the most problems where with Steam and apps that don't work with Windows version set to win98. But all this may be the fault of those users and i never tried winetools my self... So better ask your users if you want to make winetools better. Jan

March 13, 2006

Re: dlls: Move the call to MODULE_DllThreadAttach from kernel32 code to NTDLL code

by Alexandre Julliard

Robert Shearman <rob(a)codeweavers.com> writes: > ChangeLog: > Move the call to MODULE_DllThreadAttach from kernel32 code to NTDLL code. The problem with this is that the call is no longer inside the exception handler, so it would prevent debugging crashes that happen during thread attach. -- Alexandre Julliard julliard(a)winehq.org

March 13, 2006

Re: wine dev packages

by Segin

Jason Green wrote: >>I just added the Fedora Core 5 and Ubuntu Dapper sections yesterday, >>and I believe that they are at least 95% accurate, although I might >>have missed one somewhere. If someone can add the package names >>required for a gentoo build (or possibly create and maintain wine-cvs >>packages with all of the necessary deps???), it would probably help >>out many users trying to compile from source. >> Gentoo users have a Wine ebuild to build from CVS, with version major '9999' Simply put, you install the latest Wine CVS like this: emerge =wine-9999 and it also pulls all deps.

March 13, 2006

Re: GDI32: using the embeded bitmap in antialias mode

by Byeong-Sik Jeon

2006-03-13 (월), 04:10 +0900, Byeong-Sik Jeon 쓰시길: > If format == WINE_GGO_GRAY16_BITMAP at the "WineEngGetGlyphOutline()", > set on "FT_LOAD_NO_BITMAP". > I mistake. When format == WINE_GGO_GRAY16_BITMAP, skip that set on "FT_LOAD_NO_BITMAP".

March 12, 2006

Re: ddraw design flaw

by Tomas Carnecky

Stefan Dösinger wrote: > Hi, >> I have found a design flaw in ddraw and described it in my 'World of >> Warcraft 0.10 Public Test Real (PTR)' thread. Why has nobody adressed >> this issue? In my eyes it is a severe design flaw if an application >> can't unload ddraw.dll without side effects (especially if this >> side-effect is that all opengl/directx applications are unusable after >> that). > The ddraw implementation has some unloading bugs at the moment. Not restoring > the glx context(that's the problem you reported, right) is only one of them. > Another is that the screen resolution isn't restored when the app doesn't > care for releasing it's object. > > I have this problem in mind, and I'll check WineD3D for it, as it most likely > affects all D3D libs. Once it's fixed in wineD3D and ddraw uses wineD3D for > rendering, this should be sorted out. > > Sorry for not fixing this at once, but time is limited ;). If you want a > solution now, you're free to fix ddraw. But I registered that issue and it's > on my lenghty todo list. > > Thanks for the info. It's good to see that it's a known issue and that it's on someones TODO list. I'm trying to find out whether Survey.dll will be part of the final 1.10 release or if it's only part of the PTR client. I haven't had any luck so far. I don't know why Blizzard doesn't want to give me this information, we'll find out sooner or later (eg. the day when they release 1.10), it just would be nice to know whether the WoW players need a patch or not. I'm not very familiar with wine so I probably won't be able to write a better patch. tom

March 12, 2006

Re: [Bugzilla] Add note to not paste logs and back traces.

by Tony Lambregts

James Trotter wrote: > > > On 3/12/06, *Jesse Allen* <the3dfxdude(a)gmail.com > <mailto:the3dfxdude(a)gmail.com>> wrote: >> >> Yeah, that's bad, but so is this AppDB page: >> http://appdb.winehq.org/appview.php?versionId=1177 >> >> People seem to think that the AppDB comment sections are a good place >> to post logs. It made the page really long. So I put this as the >> first thing in the howto: >> >> "Reporting Problems >> >> If you encounter a problem, send your report to Wine-Users Mailing >> List or WineHQ Bugzilla. These places are much faster for getting >> help, and bugzilla is better for posting logs." >> >> And it mostly seemed to work. And there are alot more new bug links >> now. But then they added the "testing" section and people use that >> too to report their problems and for pasting logs. I wish they would >> be brief in those and link to bug #'s instead. >> >> And true it is the same that the logs aren't good in the bugzilla >> comments either. They should upload them seperate. I guess there are >> a lot of new people that haven't dealt with this system. The new note >> should help. >> >> One of these days I'd really like to clean up the old comments on the >> AppDB page, but I don't want to scare anyone with mass deletions. It >> takes a long time to load on dialup. > > I'm curious what the policy about cleaning up comments on the appdb is. If a > user posts about a comment about some problem with the application, and the > problem later is fixed, should the comment be removed? Yes these can be deleted > What about bug links? Should they be removed once the bug is fixed or closed? > No at least for now. There probably should be an option to hide resolved and closed bugs though. > > The maintainer's guidelines page says: "If a comment is useless or is not > true anymore, you can safely delete it." Though, if you look at AppDB entries > like the one above, this doesn't seem to happen. Perhaps the maintainer's > guidelines could be a bit more specific? That seems pretty straight for ward to me. Could you clarify what you mean. > Also, the guidelines don't even mention bug links. > Well the guideline is not to delete bug links unless they never did apply to the application version. (If the bug link was submitted in error then delete it) -- Tony Lambregts

March 12, 2006

Re: RFC: Make SetThreadContext work properly

by Vitaliy Margolen

Sunday, March 12, 2006, 7:18:30 AM, Dimi Paun wrote: > Hi Alexandre, >>From a quick look at the code, it seems that you've already fixed > the problem addressed by Mike's patch: > http://wiki.winehq.org/Make_SetThreadContext_work_properly > revision 1.53 > date: 2006/01/11 20:36:17; author: julliard; state: Exp; lines: +38 > -24 > Alexandre Julliard <julliard(a)winehq.org> > ntdll: Handle NtSetContextThread on the client side (as far as > possible) when setting the context of the current thread. > Just checking so I can remove the patch from the wiki if it's > no longer relevant. Yes it is fixed with that Alexandre's patch you mentioned. Vitaliy.

March 12, 2006

wine dev packages (was: Can't run DirectX games on x86_64 Linux)

by Detlef Riekenberg

Jason Green wrote: > Correct, wine will compile and run without a lot of features and never > warn you that they don't exist. See this wiki page for an example of > what your include/config.h file should probably look like: > > http://wiki.winehq.org/Recommended_Packages > > I just added the Fedora Core 5 and Ubuntu Dapper sections yesterday, > and I believe that they are at least 95% accurate, although I might > have missed one somewhere. If someone can add the package names > required for a gentoo build (or possibly create and maintain wine-cvs > packages with all of the necessary deps???), it would probably help > out many users trying to compile from source. IMHO, wine-cvs with all packages is not a good idea. I'm testing xubuntu and i do not want to install kde/gnome. Using multiple packages (wine-kde-cvs / wine-gnome-cvs / ...) are hard to maintain. And what about the different audio-driver? Even more difficult is the OpenGL-Part (mesa / nvidia / ati) I split the List in the Wiki to make clear, for which dlls which packages are needed. The split is not complete yet, and IMHO the List is also wrong (examples: libusb-dev, libqt3-mt-dev) Feel free to update Fedora similar. -- By by ... Detlef

March 12, 2006

RFC: Make SetThreadContext work properly

by Dimi Paun

Hi Alexandre, >From a quick look at the code, it seems that you've already fixed the problem addressed by Mike's patch: http://wiki.winehq.org/Make_SetThreadContext_work_properly revision 1.53 date: 2006/01/11 20:36:17; author: julliard; state: Exp; lines: +38 -24 Alexandre Julliard <julliard(a)winehq.org> ntdll: Handle NtSetContextThread on the client side (as far as possible) when setting the context of the current thread. Just checking so I can remove the patch from the wiki if it's no longer relevant. -- Dimi Paun <dimi(a)lattica.com> Lattica, Inc.

March 12, 2006

Re: My guess why Munich doesn't like Wine

by Tom Wickline

On 3/12/06, Dan Kegel <dank(a)kegel.com> wrote: > > Given that the world kind of treats this as a must, > perhaps it could be added as a criterion for > a 1.0 release. Say, where's the existing page > describing our release criteria? The page we had was for a 0.9 release, I suppose the criteria for the 1.0 release will be discussed at this year's conference. Tom > - Dan > > -- > Wine for Windows ISVs: http://kegel.com/wine/isv > > >

March 12, 2006

Re: [Bugzilla] Add note to not paste logs and back traces.

by James Trotter

On 3/12/06, Jesse Allen <the3dfxdude(a)gmail.com> wrote: > > On 3/11/06, Vitaliy Margolen <wine-devel(a)kievinfo.com> wrote: > > What? You mean having all the pastes in this bug: > http://bugs.winehq.org/show_bug.cgi?id=4131 > > adds to it's readability? This is just one bug that I could think of. > > Also note that the biggest paste by author has nothing to do with the > bug > > itself. > > > > Vitaliy > > > > > > > > Yeah, that's bad, but so is this AppDB page: > http://appdb.winehq.org/appview.php?versionId=1177 > > People seem to think that the AppDB comment sections are a good place > to post logs. It made the page really long. So I put this as the > first thing in the howto: > > "Reporting Problems > > If you encounter a problem, send your report to Wine-Users Mailing > List or WineHQ Bugzilla. These places are much faster for getting > help, and bugzilla is better for posting logs." > > And it mostly seemed to work. And there are alot more new bug links > now. But then they added the "testing" section and people use that > too to report their problems and for pasting logs. I wish they would > be brief in those and link to bug #'s instead. > > And true it is the same that the logs aren't good in the bugzilla > comments either. They should upload them seperate. I guess there are > a lot of new people that haven't dealt with this system. The new note > should help. > > One of these days I'd really like to clean up the old comments on the > AppDB page, but I don't want to scare anyone with mass deletions. It > takes a long time to load on dialup. > > > I'm curious what the policy about cleaning up comments on the appdb is. If a user posts about a comment about some problem with the application, and the problem later is fixed, should the comment be removed? What about bug links? Should they be removed once the bug is fixed or closed? The maintainer's guidelines page says: "If a comment is useless or is not true anymore, you can safely delete it." Though, if you look at AppDB entries like the one above, this doesn't seem to happen. Perhaps the maintainer's guidelines could be a bit more specific? Also, the guidelines don't even mention bug links. -James

March 12, 2006

Re: Francois Gouget : user32: Handle WM_ENDSESSION in DefWinProc().

by Rein Klazes

On Sat, 11 Mar 2006 19:23:14 -0800, you wrote: >Pardon intrusion by this Wine user into this technical discussion. > >Is the problem with Pegasus Mail (PM) that is mentioned below something that is >new with Wine 0.9.9? I know that I saw termination of "the complete program" >whenever I sent a message using PM 4.31 and Wine 0.9.9. As a result I've >reverted to Wine 0.9.8 and have none of this. You do not even have to send the message, just closing the compose new message window is enough. Yes, it is new in 0.9.9. Rein.

March 12, 2006

Re: [Bugzilla] Add note to not paste logs and back traces.

by Rein Klazes

On Sat, 11 Mar 2006 12:30:39 -0700, you wrote: >> Not pasting back traces will make following the bug list by email rather >Well it might be true, but to a point. Most of the debug traces are too >wide and e-mail wraps them (so does maillist archive). That _does_ make >it nearly impossible to see anything. I said "backtraces". You talk about debug traces, the backtraces are good to follow. I agree that logs are mostly too large to post, but then most people already attach those. > >> useless. IMO what people are currently posting in bugzilla do not >> require such recommendations. > >What? You mean having all the pastes in this bug: http://bugs.winehq.org/show_bug.cgi?id=4131 >adds to it's readability? Honestly I do not see your problem here. To me it is readable both on the web and by email. Perhaps the web form could be reversed so that new reactions are on top, if the scrolling is your problem. Rein.

March 12, 2006

My guess why Munich doesn't like Wine

by Dan Kegel

After poking at the apps they tested with, the conclusion is: they wanted something that could run Access and Oracle client apps, and Wine just wasn't there yet. It still isn't, judging by my quick tests. Given that the world kind of treats this as a must, perhaps it could be added as a criterion for a 1.0 release. Say, where's the existing page describing our release criteria? - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

March 12, 2006

Oracle Express Client under Wine - install fails in advapi.CreateService

by Dan Kegel

At the risk of posting too much information, here's another roadblock faced by an important potential user. keeptool.com's hora.exe (one of the apps needed by the european government desktop migration) is an Oracle DBA helper tool, and testing it means connecting to an Oracle database. That means, I think, installing the Oracle client library under Wine. Sadly, this fails during install; the installer claims that advapi.CreateService is crashing. ( See http://bugs.winehq.org/show_bug.cgi?id=4802 ) Somebody with a little free time could probably learn more by adding more trace statements in CreateService. - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

March 12, 2006

Re: Francois Gouget : user32: Handle WM_ENDSESSION in DefWinProc().

by James E. Lang

Pardon intrusion by this Wine user into this technical discussion. Is the problem with Pegasus Mail (PM) that is mentioned below something that is new with Wine 0.9.9? I know that I saw termination of "the complete program" whenever I sent a message using PM 4.31 and Wine 0.9.9. As a result I've reverted to Wine 0.9.8 and have none of this. -- Jim Rein Klazes wrote at 15:20 on 11 Mar 2006: > On Fri, 24 Feb 2006 14:29:45 -0600, you wrote: > > > >Author: Francois Gouget <fgouget(a)codeweavers.com> > >Date: Fri Feb 24 15:34:09 2006 +0100 > > > >user32: Handle WM_ENDSESSION in DefWinProc(). > >DefWinProc() should call PostQuitMessage() on WM_ENDSESSION if the > >shutdown is proceeding. > > Hi Francois, > > This patch is causing a problem in Pegasus Mail. Closing some dialogs > cause termination of the complete program. <snip>

March 12, 2006

Re: spss can't even install...

by Willie Sippel

Am Samstag, 11. März 2006 07:06 schrieb Dan Kegel: > p.s. one downside of using wine to run firefox as your main > browser is it's a bit more dangerous to do the > rm -rf ~/.wine > needed to do a really clean install of a test app :-) > so this test was done with a fairly cluttered fake wine directory. > But it seems to match the results in the PR. Why not simply use a seperate dir for your experiments? "WINEPREFIX=~/.winetest wineprefixcreate" and "WINEPREFIX=~/.winetest wine $RANDOM_TEST_APP" should be all you need, no? ;-) -- Willie Sippel //////// | Tritium Studios // | ______________________________ //// /// | http://www.tritium-studios.com <willie(a)froq.net>

March 12, 2006

DDraw over WineD3D - Indexed colour visuals

by Adam Luchjenbroers

I've been using and tracking Stefan Dossinger's work re: DDraw over WineD3D and decided try and find out if IWineD3DSurface was far enough along to be able to be used in place of IWineX11Surface for 2d applications (Hopefully to eliminate depth conversion issues). Short answer, no. Long answer, Screen displays blank, trace log shows that glReadPixels at line 615 in wined3d\surface.c (LockRect) is failing with error GL_INVALID_OPERATION. Further investigation reveals that this is because glFormat is GL_COLOR_INDEX, yet the display is an RGB visual (presumably because an indexed colour visual was not available, and this buffer is connected directly to the screen). I figured I'd look to the people already familiar with the WineD3D\DDraw codebase before I tried to figure out my own solution. -- "Most people would rather die than think; in fact, they do so." - Bertrand Russell (1872 - 1970)

March 12, 2006

Re: [Bugzilla] Add note to not paste logs and back traces.

by Jesse Allen

On 3/11/06, Vitaliy Margolen <wine-devel(a)kievinfo.com> wrote: > What? You mean having all the pastes in this bug: http://bugs.winehq.org/show_bug.cgi?id=4131 > adds to it's readability? This is just one bug that I could think of. > Also note that the biggest paste by author has nothing to do with the bug > itself. > > Vitaliy > > > Yeah, that's bad, but so is this AppDB page: http://appdb.winehq.org/appview.php?versionId=1177 People seem to think that the AppDB comment sections are a good place to post logs. It made the page really long. So I put this as the first thing in the howto: "Reporting Problems If you encounter a problem, send your report to Wine-Users Mailing List or WineHQ Bugzilla. These places are much faster for getting help, and bugzilla is better for posting logs." And it mostly seemed to work. And there are alot more new bug links now. But then they added the "testing" section and people use that too to report their problems and for pasting logs. I wish they would be brief in those and link to bug #'s instead. And true it is the same that the logs aren't good in the bugzilla comments either. They should upload them seperate. I guess there are a lot of new people that haven't dealt with this system. The new note should help. One of these days I'd really like to clean up the old comments on the AppDB page, but I don't want to scare anyone with mass deletions. It takes a long time to load on dialup.

March 12, 2006

Re: Francois Gouget : user32: Handle WM_ENDSESSION in DefWinProc().

by Francois Gouget

Hi, Rein Klazes wrote: [...] > This patch is causing a problem in Pegasus Mail. Closing some dialogs > cause termination of the complete program. > Here is a part of SPY++ log when run under win2000, when I close the > edit new mail dialog: > > |<00202> 00130A82 S ..........................WM_SYSCOMMAND uCmdType:SC_CLOSE xPos:672 yPos:121 [wParam:0000F060 lParam:007902A0] > |<00203> 00130A82 S ...........................WM_CLOSE wParam:00000000 lParam:00000000 > |<00204> 00130A82 S ............................WM_QUERYENDSESSION nSource:1 (End Task from Task List dialog) [wParam:00000001 lParam:00000000] > |<00951> 00130A82 R ............................WM_QUERYENDSESSION fShutdownIsOk:True [lResult:00000001] > ... > |<00952> 00130A82 S ............................WM_ENDSESSION fEndSession:True [wParam:00000001 lParam:00000000] > |<00953> 00130A82 R ............................WM_ENDSESSION lResult:00000000 > > The WM_QUERYENDSESSION and WM_ENDSESSION are sent by the program: > > |0009:Call user32.SendMessageA(00030024,00000011,00000001,00000000) ret=0040641d It's pretty weird that the application is sending a WM_QUERYENDSESSION/WM_ENDSESSION to itself. > How did you check the behavior of the Windows DefWindowProc? If I put a > DefWindowProc(hwnd, WM_ENDSESSION, 1, 0); some where in a windows > program nothing happens, while a PostQuitMesage certainly closes the > app. I used a modified poppad sample app from Petzold and used Spy++ to check that a WM_ENDSESSION caused the app to exit eventhough that application's main loop did not contain any special handling for WM_ENDSESSION. So, since the decision to exit on WM_ENDSESSION is not made in the application's main loop I placed it in the DefWindowProc. But I must have gotten some detail wrong. Unfortunately I'm away from my computer for the next week, so I can't investigate right now. -- Francois Gouget fgouget(a)codeweavers.com

March 11, 2006

Re: "IE5 or higher required". Grr.

by Stefan Dösinger

Hi, > That's exactly right (wish I'd thought to try WINEDEBUG=+file). > touch ~/.wine/drive_c/windows/system32/shdocvw.dll > fixes it (thanks to Tony for the tip). Thanks for the hint - Need for Speed Porsche Unleashed Demo needs ddraw.dll, as I found out this way ;)

March 11, 2006

Re: DDraw over WineD3D - Indexed colour visuals

by Stefan Dösinger

Hi, > Long answer, Screen displays blank, trace log shows that glReadPixels at > line 615 in wined3d\surface.c (LockRect) is failing with error > GL_INVALID_OPERATION. Further investigation reveals that this is because > glFormat is GL_COLOR_INDEX, yet the display is an RGB visual (presumably > because an indexed colour visual was not available, and this buffer is > connected directly to the screen). That is not supported right now. My current priority is to get all previously supported apps working in the way they where working before. Roderic has posted a patch for the current ddraw code to address this, this could be used to extend WineD3D. At the moment I have problems with LockRect / UnlockRect, described here: http://archives.free.net.ph/message/20060213.220622.51814d8e.en.html (The sf.net archives broke the attachmet). This is needed for DDraw, and it's also a showstopper for many D3D7 games. So what's basically needed for DDraw over opengl: * Indexed colours * Better UnlockRect code * Handling for all Blit cases in BltOverride * A opengl accellerated BltFast override

March 11, 2006

Re: Can't run DirectX games on x86_64 biarch Linux SOLVED

by Christian Schneider

Am Mittwoch, den 08.03.2006, 00:09 +0100 schrieb Christian Schneider: > Hi all. > > About half a year ago I replaced my old desktop by an AMD64 box and my > previous x86 Linux from Scratch (LFS) installation by a x86_64 multilib > LFS. And since then I'm not able to run any DirectX title anymore that > used to work before. > > This is the way I usually compile wine (GCC 3.4.4): > > ./configure --prefix=/opt/wine-CVS20060307 \ > --x-libraries=/usr/X11R6/lib && > make depend && make && su -c "make install" > > Here are some games that used to work on my old LFS, their behaviour and > the error messages. I've also attached a short log of each game to this > messages. All these logs have been recorded with the CVS version of wine > from 2006/03/05. > > Age of Empires 2 starts up, I can hear sound. When I click on "Single > Player", the game hangs with the following message: > > err:seh:setup_exception stack overflow 24 bytes in thread 0009 eip 55726262 esp 55ca0fe8 stack 0x55ca1000-0x55db0000 > > Backgammon Pro is an older (7 years or so) backgammon game, quite simple > and 2D, but uses DirectDraw. It crashes at startup: > > err:ntdll:RtlpWaitForCriticalSection section 0x5574d040 "directory.c: dir_section" wait timed out in thread 000b, blocked by 000c, retrying (60 sec) > err:seh:raise_exception Unhandled exception code c0000194 flags 0 addr 0x55701230 > > Diablo 2 VidTest (D2VidTest.exe) runs fine and suggests Direct3D for > rendering. When I click on the ok-button to quit, it keeps hanging: > > err:ntdll:RtlpWaitForCriticalSection section 0x6ffa0730 "?" wait timed out in thread 0009, blocked by 000a, retrying (60 sec) > > Diablo 2 crashes at startup after some time: > > err:ntdll:RtlpWaitForCriticalSection section 0x5574d6c0 "virtual.c: csVirtual" wait timed out in thread 0010, blocked by 0000, retrying (60 sec) > err:seh:raise_exception Unhandled exception code c0000194 flags 0 addr 0x55701230 > > Half-Life crashes at startup: > > err:seh:setup_exception nested exception on signal stack in thread 0009 eip 55725f43 esp 55589c90 stack 0x55ca1000-0x55db0000 > > Monkey Island 4 (OpenGL-mode) crashes at startup: > > err:seh:setup_exception stack overflow 240 bytes in thread 0009 eip 557013e6 esp 55ca0f10 stack 0x55ca1000-0x55db0000 > > StarCraft starts to the title menu, but clicking on "Single Player" > crashes it: > > err:seh:setup_exception stack overflow 276 bytes in thread 0009 eip 557013e6 esp 55ca0eec stack 0x55ca1000-0x55db0000 > > WarCraft 3 (OpenGL-mode) doesn't show up anything, just hangs silently. > > As you can see, the most common errors are err:seh:setup_exception and > err:ntdll:RtlpWaitForCriticalSection. I've also done some more tests > with other games like Revolt, Anno 1503, Half-Life 2, and the errors all > look alike. > > I have tried the following things to solve the problem: > * Deleted my ~/.wine, over and over again ;-) > * Compiled wine without any optimization flags > * Compiled wine on a x86 Debian box and copied the installation > over > * Copied my ~/.wine to that Debian box, where most of the games > run fine > * Tried different wine versions, starting with pre-0.9 versions, > ending with the latest CVS version > * Used winetools to setup an environment with many native DLLs. > Installation of most of the software including IE worked fine, > but did not help though. > * Searched this mailing list archive and the web for similar > errors > > Something is definitely going wrong with this. Anybody an idea? I would > appreciate any help. > > Cheers, > > Christian Schneider I found out that the problem doesn't seem to be related DirectX nor x86_64 libs. My games were all installed on a FAT32 partition which is also available for my parallel installed Windows XP. But the programs that worked I had installed directely to drive C: (~/.wine/drive_c). Now after I installed any of the games to the fake windows directory, they worked again! Renaming the installation directory and setting a symlink to the same game directory on the FAT32 parition, and the game crashed again. The debug messages showed that the last called function always was ntdll.NtQueryDirectoryFile. Grepping this function name from the log file showed the last call to it: 0009:Call ntdll.NtQueryDirectoryFile(0000001c,00000000,00000000,00000000,55daeac8,55899bb0,00002000,00000003,00000000,55899b94,00000000) ret=559c6246 0009:Ret ntdll.NtQueryDirectoryFile() retval=80000006 ret=559c6246 0009:Call ntdll.NtQueryDirectoryFile(00000070,00000000,00000000,00000000,55dade68,558d1dd0,00002000,00000003,00000000,558d1db4,00000000) ret=559c6246 0009:Ret ntdll.NtQueryDirectoryFile() retval=00000000 ret=559c6246 0009:Call ntdll.NtQueryDirectoryFile(00000070,00000000,00000000,00000000,55dade68,558d1dd0,00002000,00000003,00000000,558d1db4,00000000) ret=559c6246 0009:Ret ntdll.NtQueryDirectoryFile() retval=00000000 ret=559c6246 0009:Call ntdll.NtQueryDirectoryFile(00000070,00000000,00000000,00000000,55dade68,558d1e28,00002000,00000003,00000000,558d1e0c,00000000) ret=559c6246 0009:Ret ntdll.NtQueryDirectoryFile() retval=80000006 ret=559c6246 000b:Call ntdll.NtQueryDirectoryFile(0000001c,00000000,00000000,00000000,55daea48,5588d4b8,00002000,00000003,00000000,5588d49c,00000000) ret=559c8246 000b:Ret ntdll.NtQueryDirectoryFile() retval=80000006 ret=559c8246 0009:Call ntdll.NtQueryDirectoryFile(0000009c,00000000,00000000,00000000,55dad048,558f2a58,00002000,00000003,00000000,558f2a3c,00000000) ret=559c6246 err:seh:setup_exception nested exception on signal stack in thread 0009 eip 55725f43 esp 55589c90 stack 0x55ca1000-0x55db0000 Now what to do. Should I open a bug report? Cheers, Christian Schneider

March 11, 2006

Re: "IE5 or higher required". Grr.

by Dan Kegel

On 3/11/06, Vitaliy Margolen <wine-devel(a)kievinfo.com> wrote: > Ah ok. I want to apologize then. I'm trying to get reasonable bug reports > with enough information so any developer can go in and look without > downloading giga-bytes of stuff to just get something like > WINEDEBUG=warn+all. Amen. I occasionally go on bug triage sprints, to help winnow out and add detail to the poor bug reports. (Heck, I even have a web page about it, http://kegel.com/wine/qa/ ) > In this particular case, I won't be surprised if all that software does > is checks for one particular file somewhere in system32 directory. That's exactly right (wish I'd thought to try WINEDEBUG=+file). touch ~/.wine/drive_c/windows/system32/shdocvw.dll fixes it (thanks to Tony for the tip). Now I just have to set up an Oracle database to test against! - Dan It's > long know outstanding problem. I think if we search bugzilla we will come > up with at least dozen of files that programs check for in this way. > > Again, sorry for the extra noise. > > Vitaliy. > > > > -- Wine for Windows ISVs: http://kegel.com/wine/isv

March 11, 2006

Re: "IE5 or higher required". Grr.

by James Liggett

I must really say I agree with you here, Jeremy. I think what Dan is doing for wine is excellent, and I for one appreciate him keeping us abreast of his efforts and the problems he encounters. The apps he's working with are really important for a lot of people, and as such they probably need our attention so we can make Wine a more viable alternative. I don't think Dan is spamming wine-devel at all; in fact I'd like to see him keep letting us know about all of these things. Just my two cents... James On Sat, 2006-03-11 at 09:27 -0600, Jeremy White wrote: > > BTW is there are some particular reason that you have to cc every > > single bug that you file to wine-devel mailing as well? I'm sorry, but > > quality of those bugs are not that good really to go directly to > > wine-devel list. With this particular bug you could at least try to find > > what is that program looks at to decide if you do have IE installed or > > not. > > I certainly don't want wine-devel to turn into wine-users, > but I think you are wrong to lump Dan's emails into that category. > > Dan is a very capable developer; he may not be the most > accomplished Wine hacker, but he is not without his chops. > Note that many of the @ucla.edu patches that come to wine-devel > are from his students. > > Further, I think that Dan is triaging issues that are > of fairly critical interest to Wine. > > For example, IE dependence is a very hard problem for Wine; > a lot of programs have that as an issue. I, for one, am > grateful to Dan for running with the Windows version > of Firefox, as it helps us be better ready to understand > how to use Firefox to solve that problem. > > Further, I happen to know that the Munich considered > using Wine for their desktop migration, and they felt that > Wine was 'awful'; so it is very interesting to me, personally, > to explore why that might be. > > Cheers, > > Jeremy > >

March 11, 2006