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

What happened to the Fedora packages?
by Neal Gompa Aug. 2, 2014

Aug. 2, 2014

What happened to the Fedora packages? They have not been updated since 0.9.2!!!! Right now it is at 0.9.10!!! Nearly every other Linux distro supported has the up to date packages!!! And why does the Red Hat packages site not go to the SourceForge site as it does for SUSE packages and the others?? I have not really had the guts to ask until now, because I thought that maybe there was a slump, but now, its getting annoying!! And Fedora just released Fedora Core 5 yesterday!!! Please tell me new packages will be ready soon!!! Compiling WINE always crashes my computer, so I prefer to use the RPMs...

10 18

winspool: ERROR_INVALID_NAME in GetDefaultPrinter() ?
by Detlef Riekenberg Oct. 9, 2013

Oct. 9, 2013

Hi. >From which configuration does the "ERROR_INVALID_NAME" came from, when calling GetDefaultPrinter(NULL, &size) and no Printer is installed? This Test is Present in the current "dlls/winspool/tests/info.c". MSDN told us, that we receive an "ERROR_FILE_NOT_FOUND", if no Printer is installed: http://msdn.microsoft.com/library/en-us/gdi/prntspol_0hma.asp I get the "ERROR_FILE_NOT_FOUND" on win98se, winme, w2k and win2003 in this Situation. -- By By ... ... Detlef

3 3

The status of the wintab dll
by Robert North Dec. 24, 2007

Dec. 24, 2007

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I think after the 10 or more patches to the Wintab dll that I submitted last month, I should say something about it's status... And of course thank Alexandre for applying those patches. P.S. I won't be available from the 15th for about a week or so. So, if you have any questions, I'm afraid you might have to be patient. Hope this is of interest to someone -Rob. ******Applications: Current status*********** ***In Painter 5 *Cursor pressure works. (Therefore is usable by most) *Cursor orientation is a little odd: The orientation maths needs to be re-done. *No eraser. Haven't yet cracked what enables the eraser. *Doesn't work in desktop mode: Need to map to desktop coordinates. *Repeats windows bugs where cursor looses pressure/orientation info almost bug for bug (Is this a feature? ;-) *Cannot detect pressure/orientation int the "Brush Tracking" window: The tablet context is attached to the main window, so no events get to the popup, even if they overlap. This is not how windows wintab functions. ***In Photoshop 6. *Can only get tablet data in desktop mode: This is because the tablet context is attached to the desktop. Which generates/receives no wine events outside desktop mode. * Eraser and pen pressure working. *But* to get them working, you must have 3 XInput devices listed in your XF86Config file, They need to be the last entries in the "ServerLayout" section and the following order: eraser, tablet mouse. This is a far from ideal way of specifying the devices Wintab should use :-/ I'll document this if someone can point me to a good place to put the docs. *******To Do************* 1. Look at X11 errors. There appear to be some errors that deny some users the ability to access Wintab enabled apps. (I think I know how to fix this) 2. Improve orientation data. Orientation comes in as X-Y coords (Implicit Z), and has to leave as spherical coords. This calculation needs to be re-done. 3. When tablet context is on top, let it read XInput events from all the app's top-level windows. (This simulates the fact that the context is usually designed to cover the whole screen) 4. When tablet context is attached to desktop, read XInput events from all the app's top-level windows. 5. Tests ~ --My current philosophy on tests is... ~ Use Photoshop & Painter, any formal tests ~ can be written if anyone else gets involved in patching Wintab, to avoid regressions, and conflict. **********Long term to do (Anyone interested?):********* There's a lot of work that could be done here, but what gets done and who does it probably depends upon whether anyone finds an app that needs these features. I'd love to implement these, but realistically, I don't foresee doing this unless someone hires me to do so ;) 1. Improve configuration of wintab. Wintab could probably do with some information entered into the config file, to avoid the user having to hack their Xfree86cfg file. 2. Handle Z-Order of context properly. This entails *sharing Z-Order between apps. *Working out exactly what role windows have in determining tablet context z-orders. *Allow tablet contexts that don't cover the whole screen/tablet. *Handle inter-application clipping of tablet contexts *Allow all application's windows to receive tablet events when tablet context is on top 3. Implement non-system tablet contexts (Where system cursor not moved by pen or mouse) 4. Unicodify 5. Implement various wintab extensions. 6. Implement wintab manager functions. 7. Tests. *********Unknowns********* 1. How are wintab contexts are raised lowered? Contexts have their own z-order independent of windows, and their own viewport concept, based upon the tablet's coordinate system, not that of the OS. It appears that entering, or clicking on the window the tablet context is attached to will raise/lower the context. But I haven't done much testing on this. In particular, what happens if more than one app request their tablet context is attached to the desktop? 2. How Painter detects the eraser. Have 3 possibilities i. Windows can detect an eraser, and sends specific messages. (I'm sure I've seen this, but can't work out where!) ii. Only works if tablet and cursors are named correctly. (Probably linked to wacom tablets only). iii. I've missed something 3. Requirements of other applications -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2-rc1-SuSE (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCC8zI2vfwxdLxwWYRAsisAJ4q2gAYTgRc6f9wDI+Ruv943eDxOQCfcl3s /ZKMUGwQOuw/SIIbOkIUbd0= =R4M7 -----END PGP SIGNATURE-----

2 1

re: What operating systems will Winelib run on non-x86 systems?
by Dan Kegel Nov. 21, 2006

Nov. 21, 2006

Hi Wei Li, last year, you asked in http://www.winehq.org/hypermail/wine-users/2004/06/0086.html > I could not find the info regarding what operating systems > (such as AIX 5L v5.2, HP-UX 11i, Solaris Release Level > 9) will Winelib run on non-x86 machines. I'll really > appreciate it if someone can provide my related link or > info. I can only find the following link regarding the > supporting OS but it does not provide Winelib's supporting > OS info: > http://www.winehq.org/site/docs/wine-faq/index 3.1. > Under what hardware > platform(s) and operating system(s) will Wine(Lib) run? I'm sorry nobody got back to you -- the wine-devel mailing list might have been a better place to ask. I believe winelib runs on the following non-x86 operating systems: Linux, Solaris, Mac OS X, and FreeBSD. There's no reason in principle it couldn't run on AIX or HP/UX. Some work has been done on an HP/UX port, but some assembly would be required to complete it: http://www.winehq.com/site/?issue=241#HP-UX%20Port Cheers, Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

3 2

re: Wine-wiki broken by design
by Dan Kegel Nov. 16, 2006

Nov. 16, 2006

Maybe the wine wiki could publish a machine-readable sitemap; see http://www.xml-sitemaps.com/ http://www.google.com/webmasters/sitemaps/docs/en/about.html That would put less load on the server than letting Yahoo and Google crawl the wiki themselves. - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

2 3

WRT failed to Build
by Detlef Riekenberg July 1, 2006

July 1, 2006

Hi. The cross-compiled WRT failed since 17. May. The native WRT failed even longer. And Ideas? -- By By ... ... Detlef

2 3

Dogfood report: Firefox autoupdate works
by Dan Kegel June 18, 2006

June 18, 2006

Windows Firefox just happily updated itself under Wine to 1.5.0.3. Nice that an uncommon code path worked fine. Firefox is solid for my uses lately. Performance could use some work (reading the wine-devel archive index gets annoying towards the end of the month when it's long, as firefox takes a long time to fetch it (?)). - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

8 16

How are we doing?
by Mike Hearn June 14, 2006

June 14, 2006

As the Summer Of Code begins and new blood joins us all at once, I thought it'd be a good time to open a discussion on how we are doing as a project. Questions to consider: * Is Wine improving or is the regression rate matching the improvement rate? * Are we producing a quality product, from the perspective of non-technical end users? (I appreciate this isn't a goal for everyone) * Are we turning away potential developers for any reason? Could we do more to attract new hackers? * Are the projects fundamental processes serving us well? * Any other thoughts for improvement? In case it's not clear, I'm talking about the project as a community adventure here rather than technical aspects of the codebase. >From my own perspective I think Wine is doing better than ever before. What prompted this email is the realisation that in the past few days I've used Wine nearly every day to run a variety of apps - from games to utilities - and it's succeeded with every single one. Not always perfect but always good enough. I am no longer surprised when Wine runs an app correctly as I was when I first came to the project, these days I nearly take it for granted. Though this may be due to having developed a feel for what will work and what won't :) So clearly we're doing something right ... I also think we are doing OK with attracting and keeping new hackers. The influx of new Direct3D talent lately is fabulous for instance. The experiences of our SoC students will be useful in assessing how to improve the learning curve and we need to tap this resource better than we did last year. In other words, I think we're doing pretty well. I feel more positive about the project that I have done for a long time. It seems like as Win32 stagnated and slowed down over the past 6 years we've been able to turn the tide and add our own code faster than Microsoft can, which is the tipping point. So areas for improvement? * We seem to be doing very well in recruiting hackers who work on one particular DLL or area and solidly improve that, but a less well when it comes to 'general purpose' hackers who just take random apps and make them work. It might just be that I'm out of touch but I don't see as much patch traffic these days along the lines of "This patch set fixes XYZ app" followed by 6 patches to 6 different DLLs. Discussion on IRC/wine-devel is * No clear roadmap to 1.0 - for 0.9 we had Dimis TODO list and it was quite satisfying to see them go green as tasks were completed. I guess we have a 1.0 TODO list too but I never see any updates to it :( * Integration with other projects is still a weak area. Desktop/kernel/X integration could all use some work. I know I know, I'm guilty in not doing my bit here too .... maybe I will find my hack-fu returning sometime soon and work on the fullscreen patch again :) * App specific patches. Well I don't expect policy here to change anytime soon but extreme cases like the WoW VMA layout problem which affects tons of users do highlight the issue. * A few random things I already got into arguments about (forums, libwine api etc) :) What do you guys think? thanks -mike

34 69

Re: Martin Fuchs : shell32: SHELL32_GetItemAttributes()
by Rein Klazes June 13, 2006

June 13, 2006

Hallo Martin. This patch is giving me trouble: >Author: Martin Fuchs <martin-fuchs(a)gmx.net> >Date: Sat Feb 11 12:16:56 2006 +0100 > >shell32: SHELL32_GetItemAttributes() >- correct documentation which incorrectly claimed not to set any > attribute bits >- retrieve file attributes using SHGetPathFromIDListW() when they are > not already present in the internal PIDL structures >- add test case to show the previously wrong folder attributes when > using absolute PIDLs >- fix some memory leaks in the tests in a couple of wine configurations that I use this leads to an infinite lop when the openfile dialog is called. The call sequence is SHELL32_GetItemAttributes->SHGetPathFromIDListW->ISF_Desktop_fnGetAttributesOf->SHELL32_GetItemAttributes which repeats until the stack overflows. Here is a part of a back trace: | 13 0x7b8533ed SHELL32_GetItemAttributes+0x2dd(psf=0x7bc6bc28, pidl=0x7bc5e058, pdwAttributes=0x7ba5ae54) [/usr/home/projects/wine/mywine/dlls/shell32/shlfolder.c:430] in shell32 (0x7b8533ed) | 14 0x7b83fcb8 ISF_Desktop_fnGetAttributesOf+0x148(iface=0x7bc6bc28, cidl=0x1, apidl=0x7ba5ae5c, rgfInOut=0x7ba5ae54) [/usr/home/projects/wine/mywine/dlls/shell32/shfldr_desktop.c:459] in shell32 (0x7b83fcb8) | 15 0x7b8288cd SHGetPathFromIDListW+0x7d(pidl=0x7bc5e058, pszPath=0x7ba5b0c0) [/usr/home/projects/wine/mywine/dlls/shell32/pidl.c:1273] in shell32 (0x7b8288cd) | 16 0x7b8533ed SHELL32_GetItemAttributes+0x2dd(psf=0x7bc6bbb8, pidl=0x7bc5e058, pdwAttributes=0x7ba5b334) [/usr/home/projects/wine/mywine/dlls/shell32/shlfolder.c:430] in shell32 (0x7b8533ed) | 17 0x7b83fcb8 ISF_Desktop_fnGetAttributesOf+0x148(iface=0x7bc6bbb8, cidl=0x1, apidl=0x7ba5b33c, rgfInOut=0x7ba5b334) [/usr/home/projects/wine/mywine/dlls/shell32/shfldr_desktop.c:459] in shell32 (0x7b83fcb8) | 18 0x7b8288cd SHGetPathFromIDListW+0x7d(pidl=0x7bc5e058, pszPath=0x7ba5b5a0) [/usr/home/projects/wine/mywine/dlls/shell32/pidl.c:1273] in shell32 (0x7b8288cd) | 19 0x7b8533ed SHELL32_GetItemAttributes+0x2dd(psf=0x7bc6dd70, pidl=0x7bc5e058, pdwAttributes=0x7ba5b814) [/usr/home/projects/wine/mywine/dlls/shell32/shlfolder.c:430] in shell32 (0x7b8533ed) A +relay,+shell log of one loop is attached below. Running wineprefixcreate or reinstalling wine.inf does not help. On a clean new installation there is no problem (but I like to keep using the old stuff with a hundred or so of installed windows programs). Any idea? Rein.

3 4

comctl32.dll: Running siap and modules under wine, first steps
by Maximiliano Curia June 12, 2006

June 12, 2006

Hi, I'm trying to use a program called "siap"[1] under wine. It's the required program to pay taxes that the Argentinian government uses. So, it's quite important for the free software community in Argentina to be able to use it in a free software environment. However, I haven't heard of any real success on it, so far. I've been trying to make it run using winetools[2], and differents versions of wine. The furthest I've gone, has been with version 20050310 and all the "plugins" that winetools provides, installed. Only then, could I install the application, run it, switch between the different modules (although it worked only sometimes), but I can't really use it. There are a couple of important widgets that seem to be incompatible with wine. But as I'm not an expert neither in Windows nor in wine, the one I could really track down is a TreeView widget (from comctl32.dll) (from the main window of the program), that is not fully implemented in wine, and by using a native comctl32.dll (I tried using the win98, winme, win2k libraries) the widget would work but some of the other stuff, like switching to one of the modules wouldn't. I made a screenshot to make this clearer, the wine version[3] and the w2k version[4]. So, what should I do next? Is there some documentation of how to implement a certain Windows widget in wine? Is anybody working in this dll, or has worked on this widget? I'd appreciate any comments. Thanks, [1] http://www.afip.gov.ar/programas/siap_main.asp (spanish only) [2] http://www.von-thadden.de/Joachim/WineTools/ [3] http://gnuservers.com.ar/~maxy/wine/siap-wine.png [4] http://gnuservers.com.ar/~maxy/wine/siap-w2k.png -- Saludos, /\/\ /\ >< `/

4 8

Quartz driver
by Emmanuel Maillard June 3, 2006

June 3, 2006

Hi all, Quartz driver is up to date on Darwine CVS. Winemine is playable on both PPC and x86 but it look fine only on PPC, x86 driver suffer strange rendering bugs. See wiki for building the driver : http://wiki.opendarwin.org/ index.php/Darwine:quartzdrv I will update wiki soon with issues and todo for Quartz driver. Cheers Emmanuel

3 2

Re: Re: Wine 1.0 Tasks
by fenix＠club-internet.fr June 2, 2006

June 2, 2006

Hi, >> (Note the #3902 should be renamed as 'DIB Engine rewrite' > >Agreed; done. http://bugs.winehq.org/show_bug.cgi?id=3902 :) >> and i don't think is mandatory for 1.0) > >Probably right. Let's create the next milestone after 1.0, say 1.1, and start >retargeting bugs we don't plan to fix for 1.0. (That's what GCC does; >some bugs they retarget early, some just before the release.) > >> But i think we must fix users most hated bugs as: >> - dsound deadlocks/craps >> - openGL problems (multi contexts, fb/visual configs) >> - lotus problems > >The OpenGL child window bug, >http://bugs.winehq.org/show_bug.cgi?id=2398 >probably won't be fixed for 1.0 because it requires >an X server change. No it must be doable without X changes (But X additions as GLX_EXT_texture_from_pixmap will help a lot). Only problem is to find time to fix it (as lionel, i have no time for now). Anyway i having a simple and downloadable application to reproduce this problem (not lightwave) must help. The only parts who really needs X change are for: - glShareList: sharing fb/visual config between exitings GLX contexts - dinput mouse management >I'm not sure lotus notes problems should block 1.0, as IBM has a native >Linux client now, but if someone wants to fix them (especially the ones >in usp10.dll netapi32.dll, that would be great. agree :) >> Note: it will be interesting to add user votes to wine-bugs (ala kde) to >> better see user needs. > >There are already user votes in bugzilla, that should suffice. >- Dan Oups i never seen it :) Regards, Raphael

9 11

Re: winspool/tests: Use 0xdeadbeef as magic Value
by Jeff Latimer June 1, 2006

June 1, 2006

A minor spelling mistake, deaddeef instread of deadbeef. Jeff Detlef Riekenberg wrote: >I was using 0x00dead00 before, but Dmitry suggested 0xdeadbeef, as this > > > >-#define MAGIC_DEAD 0x00dead00 >+#define MAGIC_DEAD 0xdeaddeef > >

2 1

wine problems on a 64bit system
by Pavel Troller June 1, 2006

June 1, 2006

Hi! As some of you know, I'm experimenting with my new 64bit systems. I've found that there are problems running a lot of applications, which normally run on a 32bit system. A typical example is IL2 Sturmovik Forgotten Battles game. On a 32bit system, with the latest wine CVS (even compiled on a 64bit system) it runs flawlessly. On a 64bit system, it just prints fixme:seh:check_no_exec No exec fault triggered at 0x6d4d08b0, enabling work-around but the workaround seems to be unefficient, because nothing more happens. With a +relay, it shows that the program is looping, executing 0009:Call msvcrt._except_handler3(7fb2faa0,7fb2fba0,7fb2f7d4,7fb2f714) ret=7bc54d65 0009:Ret msvcrt._except_handler3() retval=00000000 ret=7bc54d65 and nothing more, ad infinitum. The machines are running very similar kernels. Both are hardened with exec-shield, but even disabling it on a 64bit by 'echo 0 >/proc/sys/kernel/exec-shield' doesn't help. The 32bit works even with exec-shield enabled (and doesn't print the no-exec message). Are there chances to fix this issue ? Or is it a system problem ? With regards, Pavel Troller

6 14

Text input box with scrollbar
by Augusto Arcoverde da Rocha June 1, 2006

June 1, 2006

Hi all, Where I can find the inputbox drawing code? Some of these box appear with scrollbar when testing Action Request System application under Wine, but not under MS Windows. Thanks, Augusto Arcoverde da Rocha

3 2

Wine 1.0 Tasks
by Dan Kegel June 1, 2006

June 1, 2006

If you look at http://bugs.winehq.org/ you'll see a link on the left hand side called "1.0 Tasks", which lists the 1.0 bugs being tracked in bugzilla. Here's the URL it links to http://bugs.winehq.org/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_s… I suspect a few of these are stale, and a bunch others are missing, but I like the idea of using bugzilla to track our progress to 1.0. What other bugs should be fixed before 1.0? Let's nominate a few bugs to add to the 1.0 task list, discuss them a bit, and see what Alexandre thinks. For instance: I'd like one goal of 1.0 to be "make Windows developers take Wine seriously." To achieve that, I think 1.0 has to support at least some Microsoft development tools well, including their IDEs and debuggers. It's probably unreasonable to require 1.0 to support .NET, so maybe supporting the last pre-.NET versions of Visual C++ (6.2?) and Visual Basic (6.0?) would be a good goal. And I don't think it's that unreasonable anymore; Wine is pretty close to being able to do that. What do y'all think? - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

8 14

Re: svrapi: add stub implementation
by Robert Shearman June 1, 2006

June 1, 2006

Vitaly Lipatov wrote: >svrapi.dll is exist on Win9X OS and used in some programs. > > What programs? Is it still used even with the winver set to win2k? -- Rob Shearman

2 1

Re: wineconsole: Store the font as a DWORD_PTR.
by Detlef Riekenberg May 31, 2006

May 31, 2006

Am Mittwoch, den 31.05.2006, 16:28 +0900 schrieb Mike McCormack: > index 169f4e1..73a0987 100644 > --- a/programs/wineconsole/dialog.c > +++ b/programs/wineconsole/dialog.c > + return GetWindowLongPtr(hWnd, 0); > + HFONT hFont = (HFONT)GetWindowLongPtr(hWnd, 0L); Are 0 and 0L always the same ? (32bit and 64bit) -- By By ... ... Detlef

1 0

Re: crypt32: implement CryptBinaryToStringA and CryptStringToBinaryA
by Detlef Riekenberg May 31, 2006

May 31, 2006

Hi Juan Lang. > ChangeLog: implement CryptBinaryToStringA and CryptStringToBinaryA based > on Kai Blin's base64 encoder/decoder The Functions are not Present in every crypt_32.dll. The test will crash on win9x. (The Results from GetProcAddress are not tested) -- By By ... ... Detlef

1 0

file timestamps in a git tree
by Saulius Krasuckas May 31, 2006

May 31, 2006

I make an ugly hack in a branch at my git tree. Then I run after following after some git updates: $ git rebase master ugly_hack $ make Makefile is older than Makefile.in configure, please rerun ./configure make: *** [Makefile] Error 1 $ git checkout master $ make Makefile is older than Makefile.in configure, please rerun ./configure make: *** [Makefile] Error 1 Is this behaviour intended? I thought git would reset all the file timestamps once I switch to another (master) branch... Am I wrong?

3 3

Re: getuname: add stub implementation [try 2]
by Robert Shearman May 31, 2006

May 31, 2006

Vitaly Lipatov wrote: >+/*********************************************************************** >+ * GetUName [ 2000 / XP ] >+ * >+ * undocumented fn: GetUName() >+ * The information is not available by API. The thing MS did >+ * here -- parsing the data from nameslist.txt in the Unicode Character >+ * Database (UCD). >+ * See >+ * http://groups.google.com/groups?hl=en&threadm=ODVecQBoBHA.2416%40tkmsftngp02 >+ * RETURNS >+ * unknown >+ */ >+void WINAPI GetUName(void) >+{ >+ FIXME("stub\n"); >+} > > You should add a test for this function and document at least the number of parameters of the function. Presumably it should take some parameters or return something, or the DLL is useless. If the former is incorrect then the stack will be trashed after the call. -- Rob Shearman

1 0

Re: getuname: add stub implementation [try 2]
by Alexandre Julliard May 31, 2006

May 31, 2006

Vitaly Lipatov <lav(a)etersoft.ru> writes: > +/*********************************************************************** > + * GetUName [ 2000 / XP ] > + * > + * undocumented fn: GetUName() > + * The information is not available by API. The thing MS did > + * here -- parsing the data from nameslist.txt in the Unicode Character > + * Database (UCD). > + * See > + * http://groups.google.com/groups?hl=en&threadm=ODVecQBoBHA.2416%40tkmsftngp02 > + * RETURNS > + * unknown > + */ > +void WINAPI GetUName(void) > +{ > + FIXME("stub\n"); > +} If you don't know the parameters you should leave the function as stub in the spec file, at least this way it will crash cleanly. Also you have to make the dll handle the PREATTACH value to prevent it from getting loaded if native is present. Look at how other stub dlls are doing it. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: urlmon: Use FindMimeFromData to determine MIME type.
by Alexandre Julliard May 31, 2006

May 31, 2006

Jacek Caban <jacek(a)codeweavers.com> writes: > dlls/urlmon/binding.c | 25 ++++++++++++++++++++----- > 1 files changed, 20 insertions(+), 5 deletions(-) This breaks the tests: ../../../tools/runtest -q -P wine -M urlmon.dll -T ../../.. -p urlmon_test.exe.so url.c && touch url.ok url.c:401: Test failed: unexpected call OnProgress_MIMETYPEAVAILABLE url.c:401: Test failed: unexpected call OnProgress_MIMETYPEAVAILABLE make[1]: *** [url.ok] Error 2 -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: Re: World of Warcraft (WoW) patch/more address space layout stuff
by fenix＠club-internet.fr May 31, 2006

May 31, 2006

----Message d'origine---- >Date: Tue, 30 May 2006 16:08:42 +0200 >De: Tomas Carnecky <tom(a)dbservice.com> >A: Mike Hearn <mike(a)plan99.net> >Copie à: wine-devel(a)winehq.com, n0dalus <n0dalus(a)gmail.com> >Sujet: Re: World of Warcraft (WoW) patch/more address space layout stuff > >Mike Hearn wrote: >> It's a bug in WoW itself, it relies upon the exact way NT maps memory >> which is different to how Linux does it. I guess they are storing >> information in the high bits of a pointer somewhere or some similar >> trick. >> > >Since WoW also runs on MacOSX, how does the memory layout on MacOSX >differ from NT and Linux? Maybe that's the reason why they won't do a >Linux port: because they rely on a certain memory layout and the code >can't be changed that easily. No, they have added this regressions after a little patch-set. So they can fix it. And as we can't download a playable demo ... Regards, Raphael

5 4

--without-opengl problems
by Saulius Krasuckas May 31, 2006

May 31, 2006

If I compile Wine by starting with "./configure", it builds dlls/wined3d/wined3d.dll.so file. Then If I run some Ogre (d3d) game, I get all video setup stuff OK. If I connect to my tightvnc server after and run the game here, I get Xlib errors in the output (about missing GLX on :1.0 or a like). Then I decide to disable OpenGL support in Wine and start with "./configure --without-opengl". After this the wined3d.dll.so is left on the disk. And if later I run the game again via vnc server, I get weird errors and see Wine crashing in wined3d.dll (and sometimes wineprefixcreate crashes inside shlwapi.dll or opengl.dll). Isn't this behaviour strange a bit? Shouldn't configure delete dlls/wined3d/wined3d.dll.so or unlink dlls/wined3d.dll.so or at least define code don't try loading wined3d.dll when "--without-opengl" option is given to it? IOW, "make clean" shouldn't be necessary here, right? Well, I just may be missing some information... TIA

4 4