Re: World Of Warcraft
Hi, On Wed, Feb 16, 2005 at 01:23:08AM -0500, [EMAIL PROTECTED] wrote: fixme:thread:NtQueryInformationThread info class 9 not supported yet class 9 is ThreadQuerySetWin32StartAddress. Could be quite easy to implement... (but maybe won't change anything) Andreas Mohr
Re: [AppDB] edit version and edit notes
Le mardi 15 fvrier 2005 20:53 -0800, Scott Ritchie a crit : Cool, I can edit application version info again when I'm a maintainer (and a supermaintainer), however I still can't do it if I'm just a supermaintainer (the only button available in an app version is to resign as supermaintainer.) Thanks for reporting, I sent a patch that fixes this. Furthermore, as a related feature request, listing the names of the supermaintainers in the maintainer field when viewing a version would be useful, so that it appears that a supermaintained app is actually maintained. Thanks for the feature request, I sent another patch to show supermaintainers as well. Regards, Jonathan signature.asc Description: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=
Re: winecfg: various drive detection enhancements
Hi Richard, On Wednesday 16 February 2005 08:45, you wrote: Windows permits the user to set the name of the windows directory to whatever he desires. At one time I had directories called /Win31 and /Win98. Not a common practice, but you may wish to make provision for this if there are later revisions to the code. So the line above might look something like: cp datadir/wine.inf $CROOT_WINDOWS/inf/wine.inf if I understand your code correctly. On the other hand, there may be benefits in having a standard installation designed with a /windows directory in mind, and the wine user then handles non-standard installations with whatever skills he has available. wineprefixcreate is executed only if the user calls wine without having a '.wine' directory in place at all. What this means is that there is no registry and no configuration at all at this time. So there is no way that the user has already configured a /Win98 as the system directory or somesuch. wineprefixcreate is meant to install a default configuration for users who don't have the knowledge or the desire to do so on their own. The configuration it installs is a good starting point to be tailored to your needs, though. It won't be touched by wineprefixcreate again, once it is generated. That said, the line of code you are refering to is not from me. I've only added the call to winecfg. Ciao, -- Michael Jung [EMAIL PROTECTED]
Re: World Of Warcraft
Hi, Hi, I don't want to rush anything in this department since I know there's a massive transition from the d3d* architecture to wine3d, and I think it's a really great idea to funnel everything through opengl and only need one rendering library. It's hard for me to say as a WoW addict myself, but I would rather have a complete implementation of d3d9 than one that is only able to play WoW. So I guess what I'd like to say on this front is this: awesome work guys! :) fixme:thread:GetThreadTimes Cannot get kerneltime or usertime of other threads fixme:thread:NtQueryInformationThread info class 9 not supported yet I don't think this is a real problem The error I am able to get (when I change my winver to win2k) is an actual game error (not given by wine). This one looks like this: ERROR #0 (0x8510) Program: C:\Program Files\World of Warcraft\WoW.exe File: C:\build\buildWoW\WoW\Source\Ui\MinimapFrame.cpp Line: 1287 Expr: !(CGMinimapFrame::Initialize(): can't get render target for minimap) Well, it would better if we have the source :) But seems the game need Render On Texture support who is not supported by current Wine OpenGL implementation as on windows is an WGL extension (and GLX extensions mapping isn't done) I posted a bug about this on December 7, 2004 at this location: http://bugs.winehq.org/show_bug.cgi?id=2603 Nothing has happened yet with this bug except for someone else confirming it. As to lionel why he dont look for openGL bugs reports :p I'd appreciate it if someone could give me one of two pieces of information (both would be spectacular!): 1) What exactly is causing the problem with the opengl version, and is it easy to fix? If its really render on texture the problem, it shouldn't be too difficult to implement (using GLX buffers/pixmaps extensions i think) 2) Is there any sort of goal that the people working on d3d9 dlls have set as far as a date they would like to have it done by? Or is it just one of those It will be done when it's done sort of things? :) Well Oliver is working a lot on this tree to split into small patches, and i have to send some patches. I think it shouldn't be long before an almost working d3d9.dll Thanks in advance, Darckness Regards, Raphael pgp9y91g32SYd.pgp Description: PGP signature
Re: World Of Warcraft
Hey, On Wed, 16 Feb 2005 09:17:13 +0100, Raphael [EMAIL PROTECTED] wrote: ERROR #0 (0x8510) Program: C:\Program Files\World of Warcraft\WoW.exe File: C:\build\buildWoW\WoW\Source\Ui\MinimapFrame.cpp Line: 1287 Expr: !(CGMinimapFrame::Initialize(): can't get render target for minimap) The game worked for quite a while in the beta until Blizard had a patch a few months back breaking it. This broke both Wine and Cedega. Transgaming has now some hack in place. Their minimap will work only in the main area. As soon you go indoors (hiding it is the workaround) you will have the same error as Wine. Transgaming now advices people to run in d3d mode. So this opengl problem could be non trivial to fix. Paul
Re: portability fixes (yet another attempt)
Mike McCormack [EMAIL PROTECTED] wrote: My attempt was to impove code sharing between both projects, and this is _exactly_ what Dmitry suggested. My understanding was that Dmitry suggested you modify your headers, not ours. Thomas and Filip Navara mailed me privately and I suggested to resend the patch without strlenW/wcslen stuff since it looks very reasonable. If Alexandre will not accept the latest version of the patch due to some cosmetic requirement I'll clean it up and resubmit on my own. -- Dmitry.
Re: wine/ programs/winefile/Pt.rc programs/winecfg ...
Hi,
Alexandre Julliard escreveu:
ChangeSet ID: 16090
CVSROOT: /opt/cvs-commit
Module name: wine
Changes by: [EMAIL PROTECTED] 2005/02/14 05:12:30
In this file below, the correct is usuário, but in cvs is incorrect
usuário and I dont know how to correct...
In my tree it is correct.
Index: wine/dlls/mpr/mpr_Pt.rc
diff -u -p wine/dlls/mpr/mpr_Pt.rc:1.1 wine/dlls/mpr/mpr_Pt.rc:1.2
--- wine/dlls/mpr/mpr_Pt.rc:1.1 Wed Feb 16 09:36:32 2005
+++ wine/dlls/mpr/mpr_Pt.rc Wed Feb 16 09:36:32 2005
@@ -24,3 +24,23 @@ STRINGTABLE DISCARDABLE
{
IDS_ENTIRENETWORK Toda a rede
}
+
+IDD_PROXYDLG DIALOG LOADONCALL MOVEABLE DISCARDABLE 36, 24, 250, 154
+STYLE DS_MODALFRAME | WS_POPUP | WS_CAPTION | WS_SYSMENU
+CAPTION Entre a senha da rede
+FONT 8, Helv
+{
+ LTEXT Por favor, entre como o nome de usuário e a senha:, IDC_EXPLAIN, 40,
6, 150, 15
+
Re: Anyone have Wine PowerPoint slides?
Hi, Ira Krakow wrote: I'm giving a presentation on converting Windows programs to Linux at MIT (the Boston Linux User Group) on April 20th from 7pm to 9pm. [...] I have a feeling it's going to be pretty different from IBM's irrealistically limited take on the subject. I was wondering if anyone has any Wine PowerPoint slides? I will do the presentation in PowerPoint under Crossover Office 4.1. I can either develop the slides myself or adapt and use slides that have been developed already. Maybe something from a previous WineConf? I don't have anything Winelib oriented but I can send you the PowerPoint of the presentation I gave to Lugod. Like Jeremy's presentation it's a bit CrossOver oriented (the title is 'CrossOver and Wine'), and also has my slant towards answering the 'Why Wine is important?' question. The presentation slides are also available online there: http://www.lugod.org/presentations/crossover/ -- Francois Gouget [EMAIL PROTECTED]
Re: Cross-test failed ...
On Wed, 2005-02-16 at 00:26, Paul Millar wrote: Hi, Quick message: building cross-test died again (output below). This time its the shell32 dll tests that are causing consternation. Suggestions greatfully received. Cheers, Paul. i686-mingw32msvc-gcc generated.o shelllink.o shellpath.o shlfileop.o shlfolder.o string.o testlist.o -o shell32_test.exe -lshell32 -lole32 -lshlwapi -ladvapi32 -luuid shelllink.o(.text+0xc1): In function `path_to_pidl': /home/paulm/Testing/wine-cross-source/dlls/shell32/tests/shelllink.c:72: undefined reference to [EMAIL PROTECTED]' distcc[21503] ERROR: compile on localhost failed make: *** [shell32_test.exe] Error 1 Hi, I've send a patch to wine-patches almost an hour ago. This fixes the crosstest build and runs OK on win98/winxp/Wine. I don't know if Francois has objections to the patch? Cheers, Paul.
Re: [shell32tests/shelllink.c] Use aliases for ordinals
Hi, Paul Vriens wrote: Hi, this makes the crosstest compile work again for shell32. Result tested on win98/winxp. Changelog: Use aliases for calls to ordinals. As far as I know, SHILCreateFromPath, ILFree and ILIsEqual are all exported by name on Windows. So, IMHO, unless we find a problem running the test on some Windows versions it would be better to fix MinGW. -- Francois Gouget [EMAIL PROTECTED]
Re: [shell32tests/shelllink.c] Use aliases for ordinals
On Wed, 2005-02-16 at 10:58, Francois Gouget wrote: Hi, Paul Vriens wrote: Hi, this makes the crosstest compile work again for shell32. Result tested on win98/winxp. Changelog: Use aliases for calls to ordinals. As far as I know, SHILCreateFromPath, ILFree and ILIsEqual are all exported by name on Windows. So, IMHO, unless we find a problem running the test on some Windows versions it would be better to fix MinGW. Hi, I've looked with PEExplorer on my win2k system and I can't see them in the exported list by name. After adding a alias for SHILCreateFromPath I was able to compile the crosstest. The test (shell32_crosstest.exe) failed however with a message stating that ILFree and, after I've added an alias for that one, ILISEqual were not exported by shell32.dll. 21/28/155 and 162 are exported as ordinals by shell32.dll (version 5.0.3900.7009) on Windows 2000 Professional. Cheers, Paul.
Re: World Of Warcraft
ERROR #0 (0x8510) Program: C:\Program Files\World of Warcraft\WoW.exe File: C:\build\buildWoW\WoW\Source\Ui\MinimapFrame.cpp Line: 1287 Expr: !(CGMinimapFrame::Initialize(): can't get render target for minimap) Well, it would better if we have the source :) But seems the game need Render On Texture support who is not supported by current Wine OpenGL implementation as on windows is an WGL extension (and GLX extensions mapping isn't done) Yeah, this must be linked to our lack of support for either 'render to texture' (which should come soon for GLX) or even basic PBuffer support (as I suppose that any well programmed application would support both possibilities). I started a long time ago to add PBuffer support to Wine's OpenGL layer but never finished (just went as far as sending the patch making it possible in the WGL extension handling, did not do any actual code). I posted a bug about this on December 7, 2004 at this location: http://bugs.winehq.org/show_bug.cgi?id=2603 Nothing has happened yet with this bug except for someone else confirming it. As to lionel why he dont look for openGL bugs reports :p I must have missed this bug as otherwise I would have at least asked for an +opengl log. Anyway, I won't have time to work on any Wine stuff till .. errm ... let's say mid April (with the snow that is still falling, I may be busy for a while :-) ). Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: [shell32tests/shelllink.c] Use aliases for ordinals
Hi Francois, In an ideal world, yes we should use the names such as SHILCreateFromPath etc. and fix MinGW. However, we're not after testing MinGW, rather testing wine compared to Windows. We know MinGW buggy! But, the up-stream vendors have been reluctant to merge in changes. Because of this we've effectively forked MinGW package (albeit in a limit fashion). Every new (to MinGW) function-call in the test-suite is one that *we* have to support and will break the autobuild of winetest.exe. If we use ordinals, then winetest.exe doesn't break. At the moment, this is happening every couple of weeks or so. We're current getting about ~40% success rate in builds (this year, on average). So, perhaps I could suggest a compromise. When adding new tests, people check if they work under current MinGW. If they don't, then the ordinal is used. Once a month (or however often people care about this), we sweep up all the ordinal-based tests, patch MinGW to support them and switch back to named exports. Could we hack together a macro that switches between ordinal-based to name-based exports? That should eliminate a lot of the donkey work. Advantages: o winetest.exe build doesn't break o less work when collecting/collating patches o less work for me :) Disadvantages: o slightly more work for developers (but hopefully not *that* much more) o have to put up with ugly ordinal exports. o potential confusion at the switch over. To me, the advantages out-weight the disadvantages. Cheers, Paul. On Wednesday 16 February 2005 09:58, Francois Gouget wrote: Paul Vriens wrote: this makes the crosstest compile work again for shell32. Result tested on win98/winxp. As far as I know, SHILCreateFromPath, ILFree and ILIsEqual are all exported by name on Windows. So, IMHO, unless we find a problem running the test on some Windows versions it would be better to fix MinGW. pgpMtHx1AnKcb.pgp Description: PGP signature
Re: lotus notes regression
Hi, was there ever a fix offered so that notes will run on wine post 20041207? Mike Hearn wrote: On Tue, 28 Dec 2004 19:21:27 -0500, Paul R Streitman wrote: Patch 14725, applied 2004/12/07 11:31:53, breaks lotus notes. The symptom is a hang with the CPU at 100%, and it happens immediately if you try to click on a notes 'bookmark', or shortly after you try to do much of anything else if you try to avoid the 'bookmarks'. This is the following patch: Log message: Moved update region handling to the server. Patch: http://cvs.winehq.org/patch.py?id=14725 ie, it's a WM rewrite regression. I will investigate when I get a chance. Paul, is this Notes 6.5.1 or an earlier version? thanks -mike
Re: wine/ programs/winefile/Pt.rc programs/winecfg ...
On Wed, 16 Feb 2005, Marcelo Duarte wrote: [...] +FONT 8, Helv Is this correct? I thought that we were using MS Shell Dlg everywhere except for Japanese where we use MS UI Gothic instead. There does seem to be some inconsistencies. Two Japanese resource files use Ms Shell Dlg instead of MS UI Gothic (all the others do as expected): $ egrep ^FONT `find . -name *.rc` | grep Ja.rc | grep -v MS UI Gothic ./dlls/shell32/shell32_Ja.rc:FONT 10, MS Shell Dlg ./dlls/shell32/shell32_Ja.rc:FONT 8, MS Shell Dlg And the following resource files don't use MS Shell Dlg: $ egrep ^FONT `find . -name *.rc` | egrep -v MS (Shell Dlg|UI Gothic) ./dlls/mpr/mpr_De.rc:FONT 8, Helv ./dlls/mpr/mpr_En.rc:FONT 8, Helv ./dlls/mpr/mpr_Pt.rc:FONT 8, Helv ./dlls/mpr/mpr_Fr.rc:FONT 8, Helv ./dlls/shdocvw/En.rc:FONT 8, Helv ./dlls/shdocvw/Pt.rc:FONT 8, Helv ./dlls/shdocvw/De.rc:FONT 8, Helv ./dlls/user/resources/user32_Si.rc:FONT 8, MS Sabs Serif ./dlls/user/tests/resource.rc:FONT 8, System ./programs/taskmgr/taskmgr.rc:FONT 8, Tahoma ./programs/taskmgr/taskmgr.rc:FONT 8, Tahoma ./programs/taskmgr/taskmgr.rc:FONT 8, Tahoma ./programs/taskmgr/taskmgr.rc:FONT 8, Tahoma ./programs/taskmgr/taskmgr.rc:FONT 8, Tahoma ./programs/taskmgr/taskmgr.rc:FONT 8, Tahoma ./programs/taskmgr/taskmgr.rc:FONT 8, Tahoma ./programs/taskmgr/taskmgr.rc:FONT 8, Tahoma ./programs/winecfg/En.rc:FONT 8, MS Sans Serif ./programs/winecfg/En.rc:FONT 8, MS Sans Serif ./programs/winecfg/En.rc:FONT 8, MS Sans Serif ./programs/winecfg/En.rc:FONT 8, MS Sans Serif ./programs/winecfg/En.rc:FONT 8, MS Sans Serif ./programs/winecfg/En.rc:FONT 8, MS Sans Serif ./programs/winecfg/Nl.rc:FONT 8, MS Sans Serif ./programs/winecfg/Nl.rc:FONT 8, MS Sans Serif ./programs/winecfg/Nl.rc:FONT 8, MS Sans Serif ./programs/winecfg/Nl.rc:FONT 8, MS Sans Serif ./programs/winecfg/Nl.rc:FONT 8, MS Sans Serif ./programs/winecfg/Nl.rc:FONT 8, MS Sans Serif ./programs/winecfg/Nl.rc:FONT 8, MS Sans Serif ./programs/winecfg/Nl.rc:FONT 8, MS Sans Serif + LTEXT Por favor, entre como o nome de usuário e a senha:, IDC_EXPLAIN, This is the same thing as usuário but encoded as UTF-8. I'm not sure we're supposed to use UTF-8 in Wine's resources so that may be a problem. Something must have changed the encoding on the way. -- Francois Gouget [EMAIL PROTECTED]http://fgouget.free.fr/ Indifference will certainly be the downfall of mankind, but who cares?
CreateCaret resets caret position (while it shouldn't)
There seems to be a difference in functionality of CreateCaret between Windows (XP at least) and Wine. You can find a test program at: http://foltman.com/wintest-caret.zip Look at this code snippet: CreateCaret(hWnd, NULL, 0, 20); SetCaretPos(100,100); CreateCaret(hWnd, NULL, 10, 10); In Wine, the 2nd CreateCaret resets caret position to (0, 0). In Windows, caret position doesn't get reset - it's still positioned at (100, 100). Note that calling CreateCaret twice without DestroyCaret is not a bug (after MSDN): - - - - - cut - - - - - CreateCaret automatically destroys the previous caret shape, if any, regardless of the window that owns the caret. The caret is hidden until the application calls the ShowCaret function to make the caret visible. - - - - - cut - - - - - Is it easy to fix for anyone ? Krzysztof
Re: portability fixes (yet another attempt)
Thomas Weidenmueller wrote: I unfortunately don't know as I couldn't find referencces to the other HAVE_* definitions, which I guess are somewhere outside of wine sources. The HAVE_* definitions are set by the configure script. You need to add a test into configure.ac that detects the presence or absence of strtoulW and vnsprintf. Mike
Re: [shell32tests/shelllink.c] Use aliases for ordinals
Hi, Paul Vriens wrote: [...] I've looked with PEExplorer on my win2k system and I can't see them in the exported list by name. After adding a alias for SHILCreateFromPath I was able to compile the crosstest. The test (shell32_crosstest.exe) failed however with a message stating that ILFree and, after I've added an alias for that one, ILISEqual were not exported by shell32.dll. 21/28/155 and 162 are exported as ordinals by shell32.dll (version 5.0.3900.7009) on Windows 2000 Professional. Ok, that would be a good reason. There's something I don't understand though: when I compile the test before your changes with Visual C++ 6.0 it compiles just fine but it turns out the resulting executable imports these three APIs by ordinal. Is this something that MinGW can / should do too? And for the Winelib side of things, is this something that winebuild can do? -- Francois Gouget [EMAIL PROTECTED]
Re: [shell32tests/shelllink.c] Use aliases for ordinals
Paul Millar wrote: Hi Francois, In an ideal world, yes we should use the names such as SHILCreateFromPath etc. and fix MinGW. [...] So, perhaps I could suggest a compromise. When adding new tests, people check if they work under current MinGW. If they don't, then the ordinal is used. Once a month (or however often people care about this), we sweep up all the ordinal-based tests, patch MinGW to support them and switch back to named exports. Could we hack together a macro that switches between ordinal-based to name-based exports? That should eliminate a lot of the donkey work. Switching to ordinals only to switch back to importing by name once MinGW is fixed is madness. MinGW is an open-source project, we have already forked it, so there's no reason not to fix it. -- Francois Gouget [EMAIL PROTECTED]
Re: wine/ programs/winefile/Pt.rc programs/winecfg ...
Francois Gouget escreveu: On Wed, 16 Feb 2005, Marcelo Duarte wrote: [...] +FONT 8, Helv Is this correct? I copied the English file and only translated the strings. I thought that we were using MS Shell Dlg everywhere except for Japanese where we use MS UI Gothic instead. If this is the correct one, can leave that later I make a patch. There does seem to be some inconsistencies. Two Japanese resource files use Ms Shell Dlg instead of MS UI Gothic (all the others do as expected): $ egrep ^FONT `find . -name *.rc` | grep Ja.rc | grep -v MS UI Gothic ./dlls/shell32/shell32_Ja.rc:FONT 10, MS Shell Dlg ./dlls/shell32/shell32_Ja.rc:FONT 8, MS Shell Dlg And the following resource files don't use MS Shell Dlg: $ egrep ^FONT `find . -name *.rc` | egrep -v MS (Shell Dlg|UI Gothic) ./dlls/mpr/mpr_De.rc:FONT 8, Helv ./dlls/mpr/mpr_En.rc:FONT 8, Helv ./dlls/mpr/mpr_Pt.rc:FONT 8, Helv ./dlls/mpr/mpr_Fr.rc:FONT 8, Helv ./dlls/shdocvw/En.rc:FONT 8, Helv ./dlls/shdocvw/Pt.rc:FONT 8, Helv ./dlls/shdocvw/De.rc:FONT 8, Helv ./dlls/user/resources/user32_Si.rc:FONT 8, MS Sabs Serif ./dlls/user/tests/resource.rc:FONT 8, System ./programs/taskmgr/taskmgr.rc:FONT 8, Tahoma ./programs/taskmgr/taskmgr.rc:FONT 8, Tahoma ./programs/taskmgr/taskmgr.rc:FONT 8, Tahoma ./programs/taskmgr/taskmgr.rc:FONT 8, Tahoma ./programs/taskmgr/taskmgr.rc:FONT 8, Tahoma ./programs/taskmgr/taskmgr.rc:FONT 8, Tahoma ./programs/taskmgr/taskmgr.rc:FONT 8, Tahoma ./programs/taskmgr/taskmgr.rc:FONT 8, Tahoma ./programs/winecfg/En.rc:FONT 8, MS Sans Serif ./programs/winecfg/En.rc:FONT 8, MS Sans Serif ./programs/winecfg/En.rc:FONT 8, MS Sans Serif ./programs/winecfg/En.rc:FONT 8, MS Sans Serif ./programs/winecfg/En.rc:FONT 8, MS Sans Serif ./programs/winecfg/En.rc:FONT 8, MS Sans Serif ./programs/winecfg/Nl.rc:FONT 8, MS Sans Serif ./programs/winecfg/Nl.rc:FONT 8, MS Sans Serif ./programs/winecfg/Nl.rc:FONT 8, MS Sans Serif ./programs/winecfg/Nl.rc:FONT 8, MS Sans Serif ./programs/winecfg/Nl.rc:FONT 8, MS Sans Serif ./programs/winecfg/Nl.rc:FONT 8, MS Sans Serif ./programs/winecfg/Nl.rc:FONT 8, MS Sans Serif ./programs/winecfg/Nl.rc:FONT 8, MS Sans Serif + LTEXT Por favor, entre como o nome de usuário e a senha:, IDC_EXPLAIN, This is the same thing as usuário but encoded as UTF-8. I'm not sure we're supposed to use UTF-8 in Wine's resources so that may be a problem. Something must have changed the encoding on the way.
Re: World Of Warcraft [Half Life 2]
--- Scott Ritchie [EMAIL PROTECTED] wrote: On Wed, 2005-02-16 at 01:37 -0500, Ivan Gyurdiev wrote: Speaking of games, I am tracking how far CVS gets in installing Half Life 2, and here's the list of error messages if anyone's interested. Half Life 2 will also require Steam support, which is currently broken. Curiously, it isn't in Crossover Office 4.1. It shouldn't be too hard to get Steam working again, if someone who actually knows more about it wants to try. I think there are patches for steam support about. (i.e. they remove the steam requirement from steam games) http://www.mgforums.com/forums/showthread.php?t=34356 Thanks, Scott Ritchie ___ ALL-NEW Yahoo! Messenger - all new features - even more fun! http://uk.messenger.yahoo.com
Re: World Of Warcraft
--- Lionel Ulmer [EMAIL PROTECTED] wrote: ERROR #0 (0x8510) Program: C:\Program Files\World of Warcraft\WoW.exe File: C:\build\buildWoW\WoW\Source\Ui\MinimapFrame.cpp Line: 1287 Expr: !(CGMinimapFrame::Initialize(): can't get render target for minimap) Well, it would better if we have the source :) But seems the game need Render On Texture support who is not supported by current Wine OpenGL implementation as on windows is an WGL extension (and GLX extensions mapping isn't done) Yeah, this must be linked to our lack of support for either 'render to texture' (which should come soon for GLX) or even basic PBuffer support (as I suppose that any well programmed application would support both possibilities). I started a long time ago to add PBuffer support to Wine's OpenGL layer but never finished (just went as far as sending the patch making it possible in the WGL extension handling, did not do any actual code). ATI supports render to texture today. and OpenGL has render to texture as part of the spec. I'm going to be taking a look at the DirectX 9 render to texture implementation as soon as I've merged DirectX 9 with head, so I'll see if there's anything that could be used in OpenGL/ WGL. I'm just freeing some HDD, so that I can do a make clean, build with the DirectX 9 patches, so expect to see something today. ___ ALL-NEW Yahoo! Messenger - all new features - even more fun! http://uk.messenger.yahoo.com
Re: World Of Warcraft
2) Is there any sort of goal that the people working on d3d9 dlls have set as far as a date they would like to have it done by? Or is it just one of those It will be done when it's done sort of things? ...Last month! I'm putting together Directx9 patches today that should bring DirectX9 beyond the current DirectX 8 level, with the exception of Shaders. After that I've got a few patches to get expressions working in winedbg that need checking over. I'm not sure what I'm going to work on next, possibly more 'completeness' and performance in DirextX 9 to give applications a good chance of running as well as games, or maybe some d3dx9 work so that winelib can compile more DirextX 9, or maybe try getting Microsofts new GUI Avalon working under wine. http://www.microsoft.com/downloads/details.aspx?FamilyID=C8F904E1-B4CA-402B-ACCF-AAA2BD60DA74displaylang=en Thanks in advance, Darckness -- Stop searching forever. Happiness is unattainable. ___ ALL-NEW Yahoo! Messenger - all new features - even more fun! http://uk.messenger.yahoo.com
Re: x11drv: make minimizing windows work again
Ok, that semi-helps. Now I don't have an extra window that was showing up after minimize. But programs still don't want to stay minimized. They blink in the task bar and immediately restore themselves. Any suggestions where could it be? People have commented on this before. To reiterate: all programs (that I have) behave in this manner, not staying minimized. BTW one side affect of this patch - application icon is not displayed in the task bar anymore. Now it's back to wine's logo. Vitaliy Margolen Tuesday, February 15, 2005, 5:51:34 AM, Vitaliy Margolen wrote: changelog: - make minimized windows stay minimized
Re: World Of Warcraft
How will this work affect Direct3D8 apps? Will this work make those apps run any better (or is work to do that being done?) Also, how does the work we have here in this project compare to what TransGaming have as far as Direct3D functionality?
WM_CREATE failure and SetScrollRange argument validation
I've noticed another two things where Wine and Windows XP differ: 1. SetScrollRange(hWnd, SB_VERT, 0, -1) does nothing in WinXP, and is equivalent to SetScrollRange(hWnd, SB_VERT, 0, 0) in Wine. I guess it's true for all kinds of invalid arguments. 2. In WinXP, returning -1 from WM_CREATE causes window creation to fail - the newly created window is automatically destroyed (which sends WM_DESTROY to the window). In Wine, WM_DESTROY is not sent (which prevents the example program to finish). The short piece of relevant code can be downloaded from: http://foltman.com/wintest-scroll.zip Krzysztof
Re: World Of Warcraft
On Wed, 16 Feb 2005 01:23:08 -0500, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hi Hi, I'm the maintainer for World of Warcraft, and I've noticed a few things which have been pointed out before (on irc, bugzilla, mailing list) but have not really gotten any attention. As this is one of the most popular, if not THE most popular pc game at the moment, it seems as though it would be worthwhile to look into getting this to work if it does not require a complete rewrite of wine to do so. There are currently two things preventing operation of the game. Firstly, I'll start off by saying that there are two separate modes to run the game in. d3d9, and opengl. The d3d9 mode doesn't currently work since the support for this dll is not complete. I have been following it closely though, and I constantly find myself impressed with the amount of work being poured into it lately. I highly recommend that you try Oliver Stieber's patch. Even if buggy, I think you'll find WoW works very well. I've recently found that Star Wars: Battlefront works with it. The problem with Battlefront is it experiences heap corruption at the menu screen. I think it's related to some stencil operation. Oliver, if you read this, I have a 10 MB +heap,+d3d,+d3d_surface log, compressed bz2 no less, that may help solve this problem. Though I may wait till your next patch and then get back to you. :) As for the opengl mode, it crashes strangely just after the character loading screen, but before actually getting into the game. I'm not really sure exactly what is causing the crash. I've run several traces, and all that comes up is a large group of fixmes which look like this: fixme:thread:GetThreadTimes Cannot get kerneltime or usertime of other threads fixme:thread:NtQueryInformationThread info class 9 not supported yet The error I am able to get (when I change my winver to win2k) is an actual game error (not given by wine). This one looks like this: ERROR #0 (0x8510) Program: C:\Program Files\World of Warcraft\WoW.exe File: C:\build\buildWoW\WoW\Source\Ui\MinimapFrame.cpp Line: 1287 Expr: !(CGMinimapFrame::Initialize(): can't get render target for minimap) I posted a bug about this on December 7, 2004 at this location: http://bugs.winehq.org/show_bug.cgi?id=2603 Nothing has happened yet with this bug except for someone else confirming it. Well, I would actually like to try WoW myself. I have a friend that has the full game. I just know that the full game will load, because I brought my computer over to his house once. While he was playing the game himself, I though it might be intersesting to see if it will still run (I tried it in beta days). I mounted his samba share, and let out a snicker, because he was too involved in the game to know what I was doing. But this hinted to him I was up to something -- I told him nothing. Then when the music started playing he knew Of course I could not log in to his account while he was playing. Maybe next time. Again, you should see Oliver's patch and see if it has bugs with the minimap. I think it might cause opengl doesn't quite work there either and the d3d stuff is just an opengl wrapper. But at least we will know. I guess this is a fixable problem? Jesse
Re: [shell32tests/shelllink.c] Use aliases for ordinals
On Wednesday 16 February 2005 12:11, Francois Gouget wrote: Switching to ordinals only to switch back to importing by name once MinGW is fixed is madness. No, *implementing* the tests using ordinals, then switching to named is damage limitation in an imperfect world. It separates our buggy MinGW implementation from the work of winetest.exe, resulting in improved testing throughput. We're not trying to fix MinGW, just test Windows. MinGW is an open-source project, we have already forked it, so there's no reason not to fix it. Indeed, but the issue is that what we have is a compilation *service* that uses an incomplete MinGW. An architecture where a service breaks at random times in the future is bad/broken: the methodology is wrong and needs fixing. Still, if people don't mind the tests going AWOL for ~60% of the time, that's fine. I guess people don't, so that's OK (speak now or forever hold thy peace) Cheers, Paul. pgpg4YkC7IhWD.pgp Description: PGP signature
Re: How to install Mozilla ActiveX on demand
Marcelo Duarte wrote: Hi, The Wine asks if I want to install the Mozilla ActiveX control, however it does not give no indication as to make this. Looking for in the patches, I found failed to meet information. See: http://www.winehq.org/hypermail/wine-patches/2004/10/0492.html That indicates: [Software\\Wine\\shdocvw] 1089668326 Url=http://www.iol.ie/~locka/mozilla/MozillaControl16.exe http://www.iol.ie/%7Elocka/mozilla/MozillaControl16.exe But the correct is: [Software\\Wine\\shdocvw] 1089668326 MozillaUrl=http://www.iol.ie/~locka/mozilla/MozillaControl16.exe http://www.iol.ie/%7Elocka/mozilla/MozillaControl16.exe So, I decided to show to the user as to make this. Also I corrected a small error of presentation. Changelog: Marcelo Duarte Show to the user how to install Mozilla ActiveX on demand Why not fix the key rather than telling the user to do it? Rob
Re: How to install Mozilla ActiveX on demand
On Wed, 16 Feb 2005 10:30:55 -0600, Robert Shearman wrote: Why not fix the key rather than telling the user to do it? The reason it's not already fixed BTW is because the moment we do that, we'll overload Adam Locks server (possibly). At minimum we need to contact him and ask permission, most likely we need to arrange our own hosting for it (and maybe signature checking in case of compromised hosts/mirrors ...)
IDirect3DDevice9Impl_SetVertexShader in d3d9/vertexshader.c
Hi, I have a demo-app that calls SetVertexShader with a NULL value. According to MSDN this is valid: To set a fixed-function vertex shader (after having set a programmable vertex shader), call IDirect3DDevice9::SetVertexShader(NULL) to release the programmable shader, and then call IDirect3DDevice9::SetFVF with the fixed-function vertex format. The app bails out of course because we do not handle the NULL value. Will this be fixed in the big upcoming d3d updates? Cheers, Paul.
Re: How to install Mozilla ActiveX on demand
Mike Hearn wrote: On Wed, 16 Feb 2005 10:30:55 -0600, Robert Shearman wrote: Why not fix the key rather than telling the user to do it? The reason it's not already fixed BTW is because the moment we do that, we'll overload Adam Locks server (possibly). At minimum we need to contact him and ask permission, most likely we need to arrange our own hosting for it (and maybe signature checking in case of compromised hosts/mirrors ...) How about hosting it on SourceForge? Rob
Re: get rid of unnecessary libunicode dependencies in some more places
Thomas Weidenmueller wrote: I'm sorry I don't know how these things are handled in wine. I basically made these patches so we don't depend on libunicode in reactos anymore as these things are supported by the native api. However, these functions should now basically either link to ntdll (or in the worst case to msvcrt). I can't even compile and link wine because I haven't managed to setup a build environment... it however works fine in reactos compiling with mingw. As I'm not familiar with libc and the other stuff wine depends on, I'd appreciate if someone who has better knowledge in this area to fix these patches. It'd however be great if these libraries can be built without libunicode because it's something obsolete for reactos (and libunicode has been bugging some of us devs). How about this for ReactOS: 1. Create a replacement for include/wine/unicode.h that has the following: #define strlenW wcslen #define strcpyW wcscpy ... 2. Apply a patch to each of the DLLs that currently link with libunicode to instead link with ntdll or msvcrt. This should have the advantage that: a. It won't break things for Wine. b. It shouldn't cause that many conflicts for ReactOS as imports don't change very often at all. c. It should pacify these touchy ReactOS developers that have a problem with libunicode. Do you see any problems with this approach? Rob
Re: How to install Mozilla ActiveX on demand
On Wed, 2005-02-16 at 11:26 -0600, Robert Shearman wrote: How about hosting it on SourceForge? Yep, we could, though we'd need to either add extra code to fetch a mirror list, or hard code it (the latter is much easier :). There's also the issue of checksumming but I think we can duck that for now, if a SourceForge mirror is cracked we all have much bigger problems ...
Re: get rid of unnecessary libunicode dependencies in some more places
Robert Shearman wrote: How about this for ReactOS: 1. Create a replacement for include/wine/unicode.h that has the following: #define strlenW wcslen #define strcpyW wcscpy ... 2. Apply a patch to each of the DLLs that currently link with libunicode to instead link with ntdll or msvcrt. That's actually how I did it, i wasn't aware that wine/unicode.h had this stuff for the ports. It works fine this way, anyways sorry for any inconvenience. Best Regards, Thomas
Re: [shell32tests/shelllink.c] Use aliases for ordinals
Paul Millar [EMAIL PROTECTED] writes: On Wednesday 16 February 2005 12:11, Francois Gouget wrote: Switching to ordinals only to switch back to importing by name once MinGW is fixed is madness. No, *implementing* the tests using ordinals, then switching to named is damage limitation in an imperfect world. It separates our buggy MinGW implementation from the work of winetest.exe, resulting in improved testing throughput. We're not trying to fix MinGW, just test Windows. Actually no, fixing MinGW is a very desirable side-effect of cross-compiling our tests. If we find bugs in MinGW they should be fixed, not worked around. -- Alexandre Julliard [EMAIL PROTECTED]
Re: [shell32tests/shelllink.c] Use aliases for ordinals (resend/rediff)
Paul Vriens wrote: Hi, to ease Alexandre's work I re-diffed the patch. The consensus on wine-devel was that this patch is fine. This patch makes the crosstest compile work again for shell32. Result tested on win98/winxp/Wine/W2KProf. Changelog: Use aliases for calls to ordinals. I don't think that's what the consensus says, if a consensus there is in the first place. If I understand Filip Navara's patch correctly, it shows that the fix belongs in MinGW's shell32.def file. And if that's the case then I'm arguing this test should remain as is. As I understand it, once MinGW's file is fixed, the compiler sees that there is an ordinal associated to SHSimpleIDListFromPath and then generates an executable which imports SHSimpleIDListFromPath by ordinal. This seems to be exactly what Visual C++ does on Windows. It's perfectly acceptable to import SHSimpleIDListFromPath by name in programs compiled using Visual C++, and the resulting executable works even if shell32.dll exports this API by ordinal only. Our conformance tests should reflect that. That's because they are meant to reflect the Windows behavior (not the MinGW one), including where compilation and linking are concerned. -- Francois Gouget [EMAIL PROTECTED]
Re: [shell32tests/shelllink.c] Use aliases for ordinals (resend/rediff)
On Wed, 2005-02-16 at 19:53, Francois Gouget wrote: Paul Vriens wrote: Changelog: Use aliases for calls to ordinals. I don't think that's what the consensus says, if a consensus there is in the first place. If I understand Filip Navara's patch correctly, it shows that the fix belongs in MinGW's shell32.def file. And if that's the case then I'm arguing this test should remain as is. As I understand it, once MinGW's file is fixed, the compiler sees that there is an ordinal associated to SHSimpleIDListFromPath and then generates an executable which imports SHSimpleIDListFromPath by ordinal. This seems to be exactly what Visual C++ does on Windows. It's perfectly acceptable to import SHSimpleIDListFromPath by name in programs compiled using Visual C++, and the resulting executable works even if shell32.dll exports this API by ordinal only. Our conformance tests should reflect that. That's because they are meant to reflect the Windows behavior (not the MinGW one), including where compilation and linking are concerned. That will leave us (for a unknown period) with a non-working winetest. And as Paul Millar stated that will be the case numerous times. So maybe we should use the patch and as soon as MingW is fixed put the calls to the names back? For now calling ordinals doesn't seem that bad as the compiled versions (as you've stated) will do the same. I thought that the main purpose of conformance tests was to check the behavior on windows. If a windows program calls (somehow directly) SHSimpleIDListFromPath and friends, it will fail. The fact that the compiler 'translates' the call into a ordinal shouldn't matter then for conformance testing. Cheers, Paul.
Re: World Of Warcraft
--- Jonathan Wilson [EMAIL PROTECTED] wrote: How will this work affect Direct3D8 apps? Will this work make those apps run any better (or is work to do that being done?) It won't at the moment, but the work has been done in a way that allows DirectX8 to wrap the functionlity at a later stage, so that DirectX9 and DirectX8 share most of the same codebase. Also, how does the work we have here in this project compare to what TransGaming have as far as Direct3D functionality? on the downside.. Shaders aren't working yet, but the DirectX 8 shaders can be migrated reasonably easly. Stencil buffers aren't working properly either, which affects shadows and odd shaped windows etc... Offscreen textures aren't working fully. on the up side. Stateblock support seems to be more complete than TransGamings. Swapchains are working, transgaming doesn't have them. Non-power of two textures should work on all opengl video cards, transgaming only support a subset of cards. Querys are stubbed, and I've got a version of Occlusion query to test (but I think ATI's drivers are broken), occlusion queries may give fairly large performance increases in some games. A few other minor things like point sprites are working. With the exception of a few areas performance is on-par with cedega. I'm looking at offscreen surfaces soon. There are lots of easy performance boosters that can be implemented at somepoint. Of the games I've tested this version works more often than Cedega, but that doesn't mean too much since most games are failing with non DirectX related issues. I've been developing with an ATI graphics card, so there shouldn't be the odd dropout because of ATI driver bugs that happens with Cedega. ___ ALL-NEW Yahoo! Messenger - all new features - even more fun! http://uk.messenger.yahoo.com
Re: add RegOpenKey, RegCloseKey tests
James Hawkins [EMAIL PROTECTED] writes: The last patch forgot to close the keys opened. Use this one instead. Changelog * Add RegOpenKey, RegCloseKey tests. The tests fail on Wine. You need to add todo_wine blocks. -- Alexandre Julliard [EMAIL PROTECTED]
Re: dlls/shell32/shlfileop.c cleanup
Joris Huizer [EMAIL PROTECTED] writes: Changelog: * renamed file_operation_delete to SHFileDelete * renamed file_operation_checkFlags to SHFileCheckFlags Please don't do that. Internal functions should not be named to look like the exported ones, that's very confusing. -- Alexandre Julliard [EMAIL PROTECTED]
Re: World Of Warcraft /IDirect3DDevice9Impl_SetVertexShader
I highly recommend that you try Oliver Stieber's patch. Even if buggy, I think you'll find WoW works very well. I've recently found that Star Wars: Battlefront works with it. The problem with Battlefront is it experiences heap corruption at the menu screen. I've just put together a new patch against head. http://www.oliverthered.f2s.com/projects/wine/ This versions a had a lot of code separation work done, rendertargets are more or less fixed and texture addressing should be working properly now. I've also gone through and put in NULL checks where they seemed to be missing, including IDirect3DDevice9Impl_SetVertexShader Let me know if you get any obvious problems like applications bailing out because of missing NULL checks and I'll put them in the patches I send to wine patches. (or note the problems in the code if there non-trivial) I think it's related to some stencil operation. Oliver, if you read this, I have a 10 MB +heap,+d3d,+d3d_surface log, compressed bz2 no less, that may help solve this problem. Though I may wait till your next patch and then get back to you. :) Can you mail it to me and I'll have a look. WINEDEBUG=trace+d3d9 would also be very usefull as it logs all the relay calls between wined3d and d3d9. Again, you should see Oliver's patch and see if it has bugs with the minimap. I think it might cause opengl doesn't quite work there either and the d3d stuff is just an opengl wrapper. But at least we will know. I guess this is a fixable problem? Rendertargets are working in DirectX9, and I've got a better version in the pipeline that should be useable for wgl. Jesse ___ ALL-NEW Yahoo! Messenger - all new features - even more fun! http://uk.messenger.yahoo.com
Microsoft genuine downloads looking for wine
As some of you may know, Microsoft is planning to totally restrict access to the Microsoft download center to all non-genuine windows users. So you would expect some check for pirated copies of windows to be involved. If you visit the download center with IE you get an activex control, but if you try with Firefox, you'll have to download a little program, that returns a code you have to copy into the download page, to get access to the download you selected. By quickly looking at the program, I noticed it looks for a registry key, this key is... SOFTWARE\Wine\Wine\Config the wine configuration key. the Windows Genuine Advantage program press release http://www.microsoft.com/presspass/press/2005/jan05/01-26GenuineAdvantagePR.asp says that in the second half of 2005, all users connecting to the Microsoft download center or to windows update will have to validate their copy of windows. Interestingly if you run the validation program on wine, and the version of windows you're emulating is prior to 2000 or is windows server 20003, you get a message saying a validation code couldn't be found, because of technical difficulties or because you're running an unsupported operating system. If you set winver to win2000, you'll get a validation code that doesn't work, this may be a bug in wine, or in the validation program. A valid and working code is returned if the version is set to xp. Still, even if this is only an initial attempt, they appear to want to discriminate wine users, while this may be acceptable for operating system components/updates, this is probably a violation of anti-trust law for all other downloads. It's also the first time Microsoft acknowledges the existence of Wine. Ivan Leo.
Re: x11drv: make minimizing windows work again
On Wednesday February 16 2005 09:57 am, Vitaliy Margolen wrote: Ok, that semi-helps. Now I don't have an extra window that was showing up after minimize. But programs still don't want to stay minimized. They blink in the task bar and immediately restore themselves. Any suggestions where could it be? The patch fixes Remedy but not Hamster. I still can't minimize it or switch desktops in KDE. -- Paul Rupe [EMAIL PROTECTED]She smiled, in the end.
Re: [shell32tests/shelllink.c] Use aliases for ordinals (resend/rediff)
Paul Vriens wrote: [...] That will leave us (for a unknown period) with a non-working winetest. The patch is available already. I attached it to this email so it's easy to find, credits go to Filip Navara. So winetest surely cannot remain broken for a long time. And as Paul Millar stated that will be the case numerous times. So maybe we should use the patch and as soon as MingW is fixed put the calls to the names back? For now calling ordinals doesn't seem that bad as the compiled versions (as you've stated) will do the same. I thought that the main purpose of conformance tests was to check the behavior on windows. If a windows program calls (somehow directly) SHSimpleIDListFromPath and friends, it will fail. This just won't happen. The fact that the compiler 'translates' the call into a ordinal shouldn't matter then for conformance testing. It does. If a Windows application contains the following code: pidl=SHILCreateFromPath(pathW, pidl, NULL); That program with compile, link and run just fine with Visual C++ on Windows. If you take those sources and try to compile them with WineLib then they should compile just fine too. In particular, if it fails du to the above line then it means there is a bug in Winelib and we want to know about that. As it stands the shelllink conformance test makes sure that we handle this correctly. If we modify it to use GetProcAddress() we lose this check. Modifying the test one way and back would be a lot of work especially when it is much simpler to just use the attached patch. Also it supposes that someone actually restores the test to its current state... who? when? Finally it's just not the Wine way. -- Francois Gouget [EMAIL PROTECTED] Index: lib/shell32.def === RCS file: /cvs/src/src/winsup/w32api/lib/shell32.def,v retrieving revision 1.7 diff -u -r1.7 shell32.def --- lib/shell32.def 1 Jan 2004 11:00:43 - 1.7 +++ lib/shell32.def 16 Feb 2005 12:30:28 - @@ -32,6 +32,7 @@ [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] @162 [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] @@ -43,6 +44,7 @@ [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] @28 [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] @@ -172,11 +174,11 @@ [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] @155 [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] @21 [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
wineprefixcreate
Hiya, I was working on bug#2716 - a trap running install which turned out to be due to a missing registry key which wineprefixcreate should have created. Now I had an excuse (I deleted *.reg for another test previously!) but the reporter also got the same problem. To quote: I've installed WINE via RPM package (there's a link to Mandrake package maintainer's RPM with WINE version 20050211 on www.winehq.com). There is no wineprefixcreate in it. I downloaded source tarball, which contains this utility, but it is part of another script, which COMPILES wine and that's what i want to avoid - system based on RPM's is more easily to maintain - you don't have to search for all installed files when uninstalling (Compiled programs must always be deleted manually. :-( ) But i don't understand why running wine rundll32.exe setupapi.dll,InstallHinfSection DefaultInstall 128 wine.inf DIDN'T put it in? No error messages. (That was what i did before running any program with RPM based WINE). Although this helped, i found other problems, so i finally installed WINE from source tarball, just to be sure, there is no installation problem Can someone please clarify when wineprefixcreate is actually driven, and for an RPM (which I've never installed, so apologies) how should this problem have been created. (Mind you, in my case ie after deleting the registry, it would have been nice for it to be pre-populate with some of the keys too!) Thanks! Jason
Re: wineprefixcreate
Can someone please clarify when wineprefixcreate is actually driven, and for an RPM (which I've never installed, so apologies) how should this problem have been created. the file is there as this shot shows http://spazioinwind.libero.it/nonsolomicrosoft/public/screenshot.png I didn't write it so I'm not sure in what conditions it's run, I would think when the reg files are deleted. Anyway not a packaging bug. Ivan.
SCons, Wine, and Winelib
Ok, currently Winelib relies on GNU autoconf, makefiles and friends to get a working app. This is a bit difficult, particularly if you're not very good with makefiles (I'm attempting to learn them from scratch in order to port an application.) I just heard about the SCons project, which from what I can tell looks like it aims to be a replacement to the makefiles. Has anyone used this? http://www.scons.org/ I bring this up because it might be easier on developers to have something like Winemaker create a SCons script, rather than rely on the user to piddle around with autoconf and hacking up makefiles. Thoughts? Thanks, Scott Ritchie Usability-developer-wannabe-extrordinaire
Re: World Of Warcraft
On Wed, 16 Feb 2005 21:26:58 + (GMT) Oliver Stieber [EMAIL PROTECTED] wrote: I highly recommend that you try Oliver Stieber's patch. Even if buggy, I think you'll find WoW works very well. I've recently found that Star Wars: Battlefront works with it. The problem with Battlefront is it experiences heap corruption at the menu screen. I've just put together a new patch against head. http://www.oliverthered.f2s.com/projects/wine/ This versions a had a lot of code separation work done, rendertargets are more or less fixed and texture addressing should be working properly now. I've also gone through and put in NULL checks where they seemed to be missing, including IDirect3DDevice9Impl_SetVertexShader Let me know if you get any obvious problems like applications bailing out because of missing NULL checks and I'll put them in the patches I send to wine patches. (or note the problems in the code if there non-trivial) I think it's related to some stencil operation. Oliver, if you read this, I have a 10 MB +heap,+d3d,+d3d_surface log, compressed bz2 no less, that may help solve this problem. Though I may wait till your next patch and then get back to you. :) Can you mail it to me and I'll have a look. WINEDEBUG=trace+d3d9 would also be very usefull as it logs all the relay calls between wined3d and d3d9. Again, you should see Oliver's patch and see if it has bugs with the minimap. I think it might cause opengl doesn't quite work there either and the d3d stuff is just an opengl wrapper. But at least we will know. I guess this is a fixable problem? Rendertargets are working in DirectX9, and I've got a better version in the pipeline that should be useable for wgl. Jesse ___ ALL-NEW Yahoo! Messenger - all new features - even more fun! http://uk.messenger.yahoo.com Wow...it works! Kind of. First thing I'd like to point out is that your patch doesn't add the new stuff (d3dx9 and wineguid) to the configure script, only to the configure.ac. That caused a little problem for me since I didn't autoconf it, but was easily fixed. Compilation went perfectly and, then the fun began. Upon loading, it shows the usual intro screen. Unfortunately, there's no textures yet (as you've mentioned). It still runs though, and I can kind of make stuff out. When I began to load my character, it crashed at the same place that the opengl version crashed! It gave me this error: err:ntdll:RtlpWaitForCriticalSection section 0x3ada001c ? wait timed out in thread 000f, blocked by 0009, retrying (60 sec) err:ntdll:RtlpWaitForCriticalSection section 0x3ae7f90c DSOUND_mixlock wait timed out in thread 0012, blocked by 000f, retrying (60 sec) err:ntdll:RtlpWaitForCriticalSection section 0x3ada001c ? wait timed out in thread 0025, blocked by 0009, retrying (60 sec) I tried to get something more complete (traces and whatnot), but it seems that my wine has compiled without --debugmsg for some reason. I'll see if I can fix that at some point. Next thing I noticed was that it crashes on exit, just like cedega does (I don't care what anyone says, tg did NOT fix it in the new release and I'm still pissed at them for sucking). Here's the error message for that: ERROR #0 (0x8510) Program:H:\.wine\drive_c\Program Files\World of Warcraft\WoW.exe File: C:\build\buildWoW\ENGINE\Source\gx\CGxDeviceD3d\CGxD3dDevice.cpp Line: 614 Expr: newRefCount == 0 I'll try and get more info to send in as soon as I get debug messages working again. Thanks again for the great work!
Winelib and SCons
Ok, to be up front and honest I haven't used SCons at all yet, but if it really is an honest to god replacement for autoconf, make, and friends then I'm really excited. Why? Because this has some serious importance for Winelib. Currently, in order to port a program to Linux via Winelib, a developer needs to first make it work in MinGW (a nontrivial amount to do if you use Visual Studio). Then, the developer needs to run some Wine scripts on it to make the code compatible with GCC on Linux - this isn't so hard, and mostly involves things like switching out backslashes for forward ones. Then, the developer needs to write his own makefiles and hammer autoconf and stuff into working right. This is the hard part, and it's where I gave up when trying to port Miranda Instant Messenger with Winelib even though it worked in MinGW. There are many other open source Windows apps out there that I'd like to try porting (say, eMule), but they're currently all written in Visual Studio and getting Visual Studio support into Winelib has been on our perpetual todo list for some years now. SCons might change that. If it really does work with Visual Studio files, we could rip out the Winelib makefile stuff and replace it with SCons. What do you think? Are the SCons developers interested in helping us do this? Do any of you use Wine yourselves? Thanks, Scott Ritchie Wine guy
Re: World Of Warcraft
___ ALL-NEW Yahoo! Messenger - all new features - even more fun! http://uk.messenger.yahoo.com Wow...it works! Kind of. First thing I'd like to point out is that your patch doesn't add the new stuff (d3dx9 and wineguid) to the configure script, only to the configure.ac. That caused a little problem for me since I didn't autoconf it, but was easily fixed. Compilation went perfectly and, then the fun began. opps. Upon loading, it shows the usual intro screen. Unfortunately, there's no textures yet (as you've mentioned). It still runs though, and I can kind of make stuff out. The lack of shaders may be causing texture problems. When I began to load my character, it crashed at the same place that the opengl version crashed! It gave me this error: err:ntdll:RtlpWaitForCriticalSection section 0x3ada001c ? wait timed out in thread 000f, blocked by 0009, retrying (60 sec) err:ntdll:RtlpWaitForCriticalSection section 0x3ae7f90c DSOUND_mixlock wait timed out in thread 0012, blocked by 000f, retrying (60 sec) err:ntdll:RtlpWaitForCriticalSection section 0x3ada001c ? wait timed out in thread 0025, blocked by 0009, retrying (60 sec) That a problem with mmtimer/dsound it's been giving me no end of grief. The CriticalSection, of semephore or something is getting corrupt and the semephore isn't being released properly causing a dead lock. I've been trying to stabalise DirectX 9 and havn't looked much deaper into the fault. Try changing to alsa with hardware emmulation, it's bad and you'll probably loose sound and have mmtimer eat your CPU but it's better than a deadlock. I tried to get something more complete (traces and whatnot), but it seems that my wine has compiled without --debugmsg for some reason. I'll see if I can fix that at some point. Next thing I noticed was that it crashes on exit, just like cedega does (I don't care what anyone says, tg did NOT fix it in the new release and I'm still pissed at them for sucking). Here's the error message for that: ERROR #0 (0x8510) Program: H:\.wine\drive_c\Program Files\World of Warcraft\WoW.exe File: C:\build\buildWoW\ENGINE\Source\gx\CGxDeviceD3d\CGxD3dDevice.cpp Line: 614 Expr: newRefCount == 0 This looks like a reference counting problem on exit, I've got some more work to do in that area, as part of getting being able to reset the device. Thanks again for the great work! ___ ALL-NEW Yahoo! Messenger - all new features - even more fun! http://uk.messenger.yahoo.com
Re: World Of Warcraft
On Wed, 16 Feb 2005 23:59:55 + (GMT) Oliver Stieber [EMAIL PROTECTED] wrote: ___ ALL-NEW Yahoo! Messenger - all new features - even more fun! http://uk.messenger.yahoo.com Wow...it works! Kind of. First thing I'd like to point out is that your patch doesn't add the new stuff (d3dx9 and wineguid) to the configure script, only to the configure.ac. That caused a little problem for me since I didn't autoconf it, but was easily fixed. Compilation went perfectly and, then the fun began. opps. Upon loading, it shows the usual intro screen. Unfortunately, there's no textures yet (as you've mentioned). It still runs though, and I can kind of make stuff out. The lack of shaders may be causing texture problems. When I began to load my character, it crashed at the same place that the opengl version crashed! It gave me this error: err:ntdll:RtlpWaitForCriticalSection section 0x3ada001c ? wait timed out in thread 000f, blocked by 0009, retrying (60 sec) err:ntdll:RtlpWaitForCriticalSection section 0x3ae7f90c DSOUND_mixlock wait timed out in thread 0012, blocked by 000f, retrying (60 sec) err:ntdll:RtlpWaitForCriticalSection section 0x3ada001c ? wait timed out in thread 0025, blocked by 0009, retrying (60 sec) That a problem with mmtimer/dsound it's been giving me no end of grief. The CriticalSection, of semephore or something is getting corrupt and the semephore isn't being released properly causing a dead lock. I've been trying to stabalise DirectX 9 and havn't looked much deaper into the fault. Try changing to alsa with hardware emmulation, it's bad and you'll probably loose sound and have mmtimer eat your CPU but it's better than a deadlock. It's most likely not sound related since I don't have sound enabled in wine. I tried it anyway just to make sure though, and nothing happened. I tried to get something more complete (traces and whatnot), but it seems that my wine has compiled without --debugmsg for some reason. I'll see if I can fix that at some point. Next thing I noticed was that it crashes on exit, just like cedega does (I don't care what anyone says, tg did NOT fix it in the new release and I'm still pissed at them for sucking). Here's the error message for that: ERROR #0 (0x8510) Program:H:\.wine\drive_c\Program Files\World of Warcraft\WoW.exe File: C:\build\buildWoW\ENGINE\Source\gx\CGxDeviceD3d\CGxD3dDevice.cpp Line: 614 Expr: newRefCount == 0 This looks like a reference counting problem on exit, I've got some more work to do in that area, as part of getting being able to reset the device. Thanks again for the great work! ___ ALL-NEW Yahoo! Messenger - all new features - even more fun! http://uk.messenger.yahoo.com Another difference I noticed between this and cedega is that it loads approximately 6000x faster. I love it.
Re: SCons, Wine, and Winelib
On Wed, 16 Feb 2005 15:41:22 -0800, Scott Ritchie [EMAIL PROTECTED] wrote: Ok, currently Winelib relies on GNU autoconf, makefiles and friends to get a working app. This is a bit difficult, particularly if you're not very good with makefiles (I'm attempting to learn them from scratch in order to port an application.) I just heard about the SCons project, which from what I can tell looks like it aims to be a replacement to the makefiles. Has anyone used this? http://www.scons.org/ I bring this up because it might be easier on developers to have something like Winemaker create a SCons script, rather than rely on the user to piddle around with autoconf and hacking up makefiles. Thoughts? Thanks, Scott Ritchie Usability-developer-wannabe-extrordinaire One thing I noted on the SCons website: Built-in support for Microsoft Visual Studio .NET and past Visual Studio versions, including generation of .dsp, .dsw, .sln and .vcproj files. Sounds interesting to me. -- James Hawkins
Re: World Of Warcraft
Whoops...I feel adequately retarded. It's OBVIOUSLY a sound-related error. I'm going to go hang myself now. When I get back, I'm going to send you some traces (unless you don't want them?) of the various things that go wrong.
Re: World Of Warcraft
I tried to get something more complete (traces and whatnot), but it seems that my wine has compiled without --debugmsg for some reason. I'll see if I can fix that at some point. wine no longer uses the --debugmsg option. Use the WINEDEBUG environment variable from now on. See http://winehq.org/site/docs/wine-user/x1824 for more information. -- James Hawkins
Re: [shell32tests/shelllink.c] Use aliases for ordinals (resend/rediff)
Ultimately, its about choice. Both methods have some merit. Currently the time-to-patch (ttp 2-3 days?) is less than the mean-time-between-breakage (mtbb ~14 days). This gives us the luxury of fixing MinGW as we find new holes in it. If these two time-scales become comparable, then we're in a realm where things are breaking as fast as we can patch them and we would be constantly battling to get a version of MinGW that can produce a winetest.exe. My *guess* is that on average, the mtbb will decrease, whilst ttp remains constant. That's what it feels like. However, we can wait and see what happens :^) On Wednesday 16 February 2005 12:35, Filip Navara wrote: BTW, are there any (other) unofficial Wine patches for the MinGW W32API package? Yes. Both Hans Leidekker and myself have a suite of patches; mine are unashamedly taken from Hans (many thanks!) and I don't think there is any difference between our patch-set. On Wednesday 16 February 2005 22:25, Francois Gouget wrote: So winetest surely cannot remain broken for a long time. No, in fact its now working again, now. Just doing an end-to-end test right now. Finally it's just not the Wine way. OK, fair point. But, there's two aspects: testing the MinGW code and the winetest.exe compilation service. Whilst ttp mtbb - \delta, the service works and we can do it the Wine way (the \delta is so people retain their sanity ;) On Wednesday 16 February 2005 18:39, Alexandre Julliard wrote: Actually no, fixing MinGW is a very desirable side-effect of cross-compiling our tests. If we find bugs in MinGW they should be fixed, not worked around. OK, sure. I think it might be worth trying to push some of these patches up-stream again. That way, we are actually fixing MinGW. Paul. (as usual, just my 2c worth) pgpfjR8EYP4Vw.pgp Description: PGP signature
Re: World Of Warcraft
On Wed, 16 Feb 2005 18:56:44 -0600 James Hawkins [EMAIL PROTECTED] wrote: I tried to get something more complete (traces and whatnot), but it seems that my wine has compiled without --debugmsg for some reason. I'll see if I can fix that at some point. wine no longer uses the --debugmsg option. Use the WINEDEBUG environment variable from now on. See http://winehq.org/site/docs/wine-user/x1824 for more information. -- James Hawkins I'm aware of this, but winedbg doesn't work without it. Plus, it turns out that I compiled wine with debug completely disabled.
Re: World Of Warcraft /IDirect3DDevice9Impl_SetVertexShader
On Wed, 16 Feb 2005 21:26:58 + (GMT), Oliver Stieber [EMAIL PROTECTED] wrote: I've just put together a new patch against head. http://www.oliverthered.f2s.com/projects/wine/ OK I've tried the new patch. As for Battlefront, it fixed the heap corruption bug. So that log is obsolete. And guess what? I can load into a game match now. I played it for a minute or so. There are several graphical problems that make it hard to play. For one, it doesn't get the transparency right around the crosshairs -- ie moving around a solid block. Another problem is that the game font gets corrupted after beginning a match. I think I'll let yall get some more stuff in before I start documenting the graphical problems. It does seems stable so far, but if I do find a crashing bug I'll let you know. Maybe I'll get around to reading more on D3D. Jesse
Re: x11drv: make minimizing windows work again
Ok, that semi-helps. Now I don't have an extra window that was showing up after minimize. But programs still don't want to stay minimized. They blink in the task bar and immediately restore themselves. Any suggestions where could it be? People have commented on this before. To reiterate: all programs (that I have) behave in this manner, not staying minimized. Vitaliy Margolen Tuesday, February 15, 2005, 5:51:34 AM, Vitaliy Margolen wrote: changelog: - make minimized windows stay minimized
Re: x11drv: make minimizing windows work again
BTW one side affect of this patch - application icon is not displayed in the task bar anymore. Now it's back to wine's logo. Vitaliy Margolen Tuesday, February 15, 2005, 5:51:34 AM, Vitaliy Margolen wrote: changelog: - make minimized windows stay minimized
Re: [shell32tests/shelllink.c] Use aliases for ordinals
Francois Gouget wrote: As far as I know, SHILCreateFromPath, ILFree and ILIsEqual are all exported by name on Windows. So, IMHO, unless we find a problem running the test on some Windows versions it would be better to fix MinGW. Those functions are all exported by ordinal only from most Windows systems except maybe the Win XP versions and systems updated with the latest IE Explorer version. Rolf Kalbermatter
Re: [shell32tests/shelllink.c] Use aliases for ordinals
Francois Gouget wrote: Ok, that would be a good reason. There's something I don't understand though: when I compile the test before your changes with Visual C++ 6.0 it compiles just fine but it turns out the resulting executable imports these three APIs by ordinal. It all depends on the SDK you have installed. The Windows DLLs always exported those functions by ordinal since about Win95. The very early SDKs for Win95 included those APIs in the import libraries so calling them in an app would link fine. Then MS removed all undocumented APIs from their release SDK import libs. Later after the court case they documented most of those formely undocumented APIs and also included them back into the next SDK release. Is this something that MinGW can / should do too? Yes MinGW libraries should probably include those APIs as well in their link libraries if they want to be compatible with the current SDK. And for the Winelib side of things, is this something that winebuild can do? With proper definition in Wines spec files this should be no problem at all. Rolf Kalbermatter
Re: [shell32tests/shelllink.c] Use aliases for ordinals
Paul Millar wrote: Indeed, but the issue is that what we have is a compilation *service* that uses an incomplete MinGW. An architecture where a service breaks at random times in the future is bad/broken: the methodology is wrong and needs fixing. Still, if people don't mind the tests going AWOL for ~60% of the time, that's fine. I guess people don't, so that's OK (speak now or forever hold thy peace) I am very annoyed by the fact that the tests mostly don't build. So I agree with you. regards, Jakob
Re: portability fixes (yet another attempt)
Hi Thomas, --- Thomas Weidenmueller [EMAIL PROTECTED] wrote: I unfortunately don't know as I couldn't find referencces to the other HAVE_* definitions, which I guess are somewhere outside of wine sources. There however needs to be a macro for strtoulW which can be named differently... .e.g. HAVE__VSNPRINTF is also just undef'ed, I'm sorry I don't know if that's defined in some gcc headers (mingw at least doesn't define them), libc or somewhere else. You need to add a check to the configure and configure.ac scripts for these functions. When you run ./configure it will check to see if this function is implemented on the given platform and define as needed. Thanks Steven __ Do you Yahoo!? Take Yahoo! Mail with you! Get it on your mobile phone. http://mobile.yahoo.com/maildemo
RE: Microsoft genuine downloads looking for wine
From: Ivan Leo Puoti Interestingly if you run the validation program on wine, and the version of windows you're emulating is prior to 2000 or is windows server 20003, you get a message saying a validation code couldn't be found, because of technical difficulties or because you're running an unsupported operating system. If you set winver to win2000, you'll get a validation code that doesn't work, this may be a bug in wine, or in the validation program. When I run the validation program on my genuine Win2k system, I get the message saying a validation code couldn't be found because of technical difficulties or because I'm running an unsupported operating system. When using IE and thus the ActiveX control there is no problem and my Windows is recognized as genuine. Looks to me the standalone validation program is seriously broken Gé van Geldorp.
Re: appdb/include screenshot.php
Hello, --- WineHQ [EMAIL PROTECTED] wrote: ChangeSet ID: 16156 CVSROOT: /opt/cvs-commit Module name: appdb Changes by: [EMAIL PROTECTED] 2005/02/16 19:16:51 Would it be possible for the appdb module to go to its own cvs commit list? While I care about the commit messages to the wine module and from time to time the lostwages module I never care about whats going on in appdb. Thanks Steven __ Do you Yahoo!? Yahoo! Mail - Easier than ever with enhanced search. Learn more. http://info.mail.yahoo.com/mail_250
Re: Microsoft genuine downloads looking for wine
Ivan Leo Puoti wrote: A valid and working code is returned if the version is set to xp. Still, even if this is only an initial attempt, they appear to want to discriminate wine users, while this may be acceptable for operating system components/updates, this is probably a violation of anti-trust law for all other downloads. It's also the first time Microsoft acknowledges the existence of Wine. Ivan Leo. Let's wait until they actually do something bad before we go around accusing them, shall we? In any case, at least from a technical point of view, going around such test ought to be fairly simple. Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. Have you backed up today's work? http://www.lingnu.com/backup.html
cleanroom legalaties
I've been using GPL software, and reverse engineering for years (manuals with more than an int13 reference used to be hard to get hold of) and have just stumbled onto an interesting link. In the US there a process called 'Abstraction, Filtration, Comparison' that is used to determine if a work falls under the copyright of another work. It doesn't look like anything that affects wine, but interesting anyway. http://digital-law-online.info/lpdi1.0/treatise22.html ___ ALL-NEW Yahoo! Messenger - all new features - even more fun! http://uk.messenger.yahoo.com
Re: Microsoft genuine downloads looking for wine
I expect that the check program will be reverse engineered and cracked to return genuine even for pirate copies in fairly short order. Either that or the pirates will just grab the patches and circulate them on the pirate sites anyway.
Re: Microsoft genuine downloads looking for wine
Jonathan Wilson wrote: I expect that the check program will be reverse engineered and cracked to return genuine even for pirate copies in fairly short order. Doesn't relate to us in any way. We are not pirates. Either that or the pirates will just grab the patches and circulate them on the pirate sites anyway. That one, unfortunately, I doubt. The patches are the least interesting thing for pirates. If pirates cared about keeping their machines secure, we would have all been at a much better position today. -- Shachar Shemesh Lingnu Open Source Consulting ltd. Have you backed up today's work? http://www.lingnu.com/backup.html
Re: Microsoft genuine downloads looking for wine
Shachar Shemesh [EMAIL PROTECTED] writes: [...] In any case, at least from a technical point of view, going around such test ought to be fairly simple. ...but is likely to violate the DMCA, leaving users in a legal limbo between the DMCA and the Fair Use Doctrine. What fun. ScottG.
re: Winelib and SCons
Then, the developer needs to write his own makefiles and hammer autoconf and stuff into working right. This is the hard part, and it's where I gave up when trying to port Miranda Instant Messenger with Winelib even though it worked in MinGW. There are many other open source Windows apps out there that I'd like to try porting (say, eMule), but they're currently all written in Visual Studio and getting Visual Studio support into Winelib has been on our perpetual todo list for some years now. I doubt SCons will help here in any substantial way. Its chief appeal seems to be to people who like using python for everything, and who like badmouthing make. - Dan -- Trying to get a job as a c++ developer? See http://kegel.com/academy/getting-hired.html
