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

WINE's way to find out about MS headers?

by Christoph Frick

hiho after reading the SetProperty documentation on MSDN about the direct input interface, i found out about four "defines" that are not yet included in the dinput.h of WINE. #define DIPROP_APPDATA MAKEDIPROP(?) #define DIPROP_CPOINTS MAKEDIPROP(?) #define DIPROP_INSTANCENAME MAKEDIPROP(?) #define DIPROP_PRODUCTNAME MAKEDIPROP(?) i guess the ids they represend are not documented anywhere but the dinput.h from Microsoft. what is the "best practise" for cases like this, to add them to wine's headers? -- cu

March 9, 2006

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

by Jan Zerebecki

Hi. For Andreas Jaeger: I CCed you, because you said on http://en.opensuse.org/Wishlist_Packages_that_are_already_there that Winetools got included for the next SUSE release. I hope you are the correct person to talk to or at least can forward this to someone who is. The following might be usefull information for you: I think a quote from http://www.winehq.org/site/download somewhat sums up the cencus on this list regarding Winetools: "WineTools [is] only recommended if installation or operability of Windows software failed on pure Wine. Since WineTools radically alters your Wine configuration please do not report bugs in programs with WineTools installed. Instead contact the author of WineTools Joachim von Thadden." Some other facts: Winetools is only sporadically updated for new versions of Wine (as http://www.von-thadden.de/Joachim/WineTools/ indicates; this site also contains some warnings regarding the support status). Winetools radically alters some vital Wine settings and thus makes many other apps fail. This leads to many users asking for help in #winehq on freenode. But nobody there wants to support winetools and thus can only suggest them to remove their .wine and redo it without winetools (which usually makes it work). Currently no Winetools developer works closely with the Wine developers to correct problems of interaction between Winetools and Wine. IMHO it would be best to either not include Winetools in a distribution or find a more active developer for it who is willing to support Winetools and cooperate with Wine developers. Or at least put up a big warning where it is read by a user that installs Winetools through the distributions package management. Jan

March 9, 2006

RE: WINED3D: Implement GetCreationParameters

by Rolf Kalbermatter

Alexandre Julliard wrote: > Rolf Kalbermatter <rolf.kalbermatter(a)citeng.com> writes: > > > Alexandre Julliard schrieb: > > > >>I fail to see in how far returning an error is hiding a bug. > >>Imho if the library detects an error[*] it should pass the > >>information to the application and let the application handle > >>it. The library doesn't know if the application maybe can cope > >>with it. Just ultimately crash is a bad idea imo. > > Please be careful with how you quote text, I didn't write that, Peter > did. Sorry about that. The first draft contained the entire communication and was syntactially correct but unnecessary long. When trimming it down I messed up the quote line. Will try to not do this again in the future. Rolf Kalbermatter

March 9, 2006

Re: WINED3D: Implement GetCreationParameters

by Alexandre Julliard

Rolf Kalbermatter <rolf.kalbermatter(a)citeng.com> writes: > Alexandre Julliard schrieb: > >>I fail to see in how far returning an error is hiding a bug. >>Imho if the library detects an error[*] it should pass the >>information to the application and let the application handle >>it. The library doesn't know if the application maybe can cope >>with it. Just ultimately crash is a bad idea imo. Please be careful with how you quote text, I didn't write that, Peter did. -- Alexandre Julliard julliard(a)winehq.org

March 9, 2006

GTA/FEAR vs mscoree/.NET

by Ivan Gyurdiev

Marcus Meissner wrote: > On Sun, Oct 16, 2005 at 04:22:10PM -0400, Ivan Gyurdiev wrote: > >> Grand Theft Auto... the never ending struggle to get it working. >> >> First I thought it was broken because of OLE...subsequently found out >> the installer was freezing, because of hidden message boxes. Now I've >> managed to install it in Desktop mode, but it dies when ran, with no >> output of any kind... >> >> Investigating shows: >> >> 000b:Call kernel32.SetUnhandledExceptionFilter(2027f1a8) ret=0115fbe9 >> 000b:Ret kernel32.SetUnhandledExceptionFilter() retval=0115fb7c >> ret=0115fbe9 >> 000b:Call kernel32.GetModuleHandleA(015459f4 "mscoree.dll") ret=0115ae6b >> 000b:Call ntdll.RtlInitAnsiString(7fcaf528,015459f4 "mscoree.dll") >> ret=2018d4fc >> 000b:Ret ntdll.RtlInitAnsiString() retval=00000000 ret=2018d4fc >> 000b:Call ntdll.RtlAnsiStringToUnicodeString(7fffcbf8,7fcaf528,00000000) >> ret=2018d55b >> 000b:Ret ntdll.RtlAnsiStringToUnicodeString() retval=00000000 ret=2018d55b >> 000b:Call ntdll.RtlInitUnicodeString(7fcaf52c,7fffcc00 L"mscoree.dll") >> ret=201a554d >> 000b:Ret ntdll.RtlInitUnicodeString() retval=00000018 ret=201a554d >> 000b:Call ntdll.LdrGetDllHandle(00000000,00000000,7fcaf52c,7fcaf534) >> ret=201a555b >> 000b:Ret ntdll.LdrGetDllHandle() retval=c0000135 ret=201a555b >> 000b:Call ntdll.RtlNtStatusToDosError(c0000135) ret=201a558a >> 000b:Ret ntdll.RtlNtStatusToDosError() retval=0000007e ret=201a558a >> 000b:Ret kernel32.GetModuleHandleA() retval=00000000 ret=0115ae6b >> 000b:Call kernel32.ExitProcess(00000001) ret=0115ae8f >> 000b:Call ntdll.LdrShutdownProcess() ret=201b03bd >> >> Looks like it doesn't like the missing mscoree.dll. >> I thought the .NET framework was not a core windows dll? >> Why would it require it? Also, installing a native dll doesn't seem to >> help... >> > > You are trying to execute a .NET binary. > > Same happens for me when I run "wine f-spot.exe" ;) > > Ciao, Marcus > So, what does that mean for the end user - is there hope that in the future I'll be able to run GTA or, F.E.A.R (which has the exact same problem) under Wine? Will the wine project integrate with mono? Note: if I install a native mscoree, the applications are still not able to find it.

March 9, 2006

Re: WINED3D: Implement GetCreationParameters

by Rolf Kalbermatter

Alexandre Julliard schrieb: >I fail to see in how far returning an error is hiding a bug. >Imho if the library detects an error[*] it should pass the >information to the application and let the application handle >it. The library doesn't know if the application maybe can cope >with it. Just ultimately crash is a bad idea imo. Many applications ignore returned error codes (especially if you have to call GetLastError()) if the programmer was under the assumption that there will be never a possibility to cause an error. While this assumption may be true on Windows (or at least a certain Windows version the programmer has tested on) it is certainly not necessarily true in Wine. There could have been a Wine call just before, that was wrongly implemented, returning an invalid pointer or such. Just returning an error may hide that error for many lines, to crash in some much more unrelated area eventually. Tracking such dependant error causes is already hard enough and hiding an invalid pointer access or other invalid parameter by checking for its validness makes it even harder if an application doesn't ridicully check every possible error condition and believe me I haven't seen many programs that really do that. Crashing may be not what most end users very much like but it is in my opinion just as fine than displaying a dialog box that an unrecoverable error has occurred and that it must shut down and much better than relying on the application to actually do proper error checking, but it makes the life of every Wine programmer just a little bit easier and Wine still being far from a release state can use any help on the programmer side. Wine's policy is to do parameter checking only if Windows is doing it in all versions too and sometimes even then only when there is at least one application that depends on it to work properly. Lets look at the example at hand. There is a function that does not check the pointer in Windows. If an application crashes in that function because of that, this means basically that the application did not do proper pointer checking already and then it is very questionable that it would check the error indication of that function at all, since it wouldn't get such an error indication on Windows anyhow. Also this application will either crash on Windows too, and then it is the programmers problem to make this application behave better or it does not crash on Windows because some previous function does behave differently than the Wine equivalent and then every wine programmer would like to know as soon as possible that this error occurres, not 5000 lines further down the program. If you would talk about a stable and final Wine release (which with Wine chasing the Windows API propably never will be) this might be a little different but we talk about a software project heavily under development. Rolf Kalbermatter

March 9, 2006

Re: BF2 demo

by Ivan Gyurdiev

> Nope. I do have to use OSS instead of ALSA, Doesn't help. > or it will hang right at > the point where the "Join Game" button should get shown, but it never > gives me the "nested exception on signal stack" error. It might be > usefull to add a few traces to the debug log, eg +d3d9,+d3d,+seh and > maybe others depending on what that shows you. > I've attached the trace - I see some texture-related errors before the exception is thrown. http://bugs.winehq.org/show_bug.cgi?id=4745

March 9, 2006

Re: BF2 demo

by H. Verbeet

On 08/03/06, Ivan Gyurdiev <ivg2(a)cornell.edu> wrote: > You were able to get the BF2 demo to show something? Yes. > Is this with native d3dx9_25.dll ? Yes. > Did you run into this bug at all? > http://bugs.winehq.org/show_bug.cgi?id=4745 Nope. I do have to use OSS instead of ALSA, or it will hang right at the point where the "Join Game" button should get shown, but it never gives me the "nested exception on signal stack" error. It might be usefull to add a few traces to the debug log, eg +d3d9,+d3d,+seh and maybe others depending on what that shows you.

March 9, 2006

Re: Wine and OS X

by Jim White

Segin wrote: > Jim White wrote: > >> Segin wrote: >> >>> Obchod id wrote: >>> >>>> There could be at least mention in FAQ about possible OS x version or >>>> whether there is no plan. >>>... >>> OSx86 Wiki entry: >>> http://wiki.osx86project.org/wiki/index.php/Darwine >>> >>> Darwine project page: >>> http://darwine.opendarwin.org/ >> >> ... > If you check that wiki page, there is a .dmg for a i386 build. Cool. Hopefully Wine will soon have a volunteer to be the maintainer, and the Downloads and FAQ pages will be updated. Even without a maintainer, those pages could be updated with this information. For those who may not be clear, Darwine is not a fork of Wine, but a Wine developer forum focused on OS X (and Darwin) specific issues. And yes, while I'm harping on FAQ updating, I'm aware that needs to be done on Darwine's site too. Jim White

March 9, 2006

Re: Wine and OS X

by Segin

Jim White wrote: > Segin wrote: > >> Obchod id wrote: >> >>> Hi, >>> >>> There could be at least mention in FAQ about possible OS x version or >>> whether there is no plan. >>> >>> Best wishes >>> >>> Frantisek >>> >> It already exists, but only for Intel Macs (The name 'Wine' is a >> recursive emulator for Wine Is Not a Emulator, from the fact it >> doesn't emulate a CPU. Therefore you cannot run x86 Windows programs >> on a PowerPC Macintosh.) >> >> OSx86 Wiki entry: >> http://wiki.osx86project.org/wiki/index.php/Darwine >> >> Darwine project page: >> http://darwine.opendarwin.org/ > > > What Obchod said is that the information about Wine on OS X is not > readily apparent in the FAQ. While being obscure during the days of > PowerPC-only OS X, the question now of "What about Wine on OS X?" has > become quite frequent in the Intel-era and will become more so. > > While a download of Wine for Intel OS X is probably still a month or > two away, updating the FAQ and making a link to it from the Downloads > page would be the user-friendly thing to do (particularly since there > is bound to be a flood of inquiries when CodeWeavers makes their > CrossOver Office release). > > Jim White > > > > If you check that wiki page, there is a .dmg for a i386 build.

March 9, 2006

Re: Wine and OS X

by Jim White

Segin wrote: > Obchod id wrote: > >> Hi, >> >> There could be at least mention in FAQ about possible OS x version or >> whether there is no plan. >> >> Best wishes >> >> Frantisek >> > It already exists, but only for Intel Macs (The name 'Wine' is a > recursive emulator for Wine Is Not a Emulator, from the fact it doesn't > emulate a CPU. Therefore you cannot run x86 Windows programs on a > PowerPC Macintosh.) > > OSx86 Wiki entry: > http://wiki.osx86project.org/wiki/index.php/Darwine > > Darwine project page: > http://darwine.opendarwin.org/ What Obchod said is that the information about Wine on OS X is not readily apparent in the FAQ. While being obscure during the days of PowerPC-only OS X, the question now of "What about Wine on OS X?" has become quite frequent in the Intel-era and will become more so. While a download of Wine for Intel OS X is probably still a month or two away, updating the FAQ and making a link to it from the Downloads page would be the user-friendly thing to do (particularly since there is bound to be a flood of inquiries when CodeWeavers makes their CrossOver Office release). Jim White

March 9, 2006

Re: Wine and OS X

by Segin

Obchod id wrote: >Hi, > >There could be at least mention in FAQ about possible OS x version or >whether there is no plan. > >Best wishes > >Frantisek > > > It already exists, but only for Intel Macs (The name 'Wine' is a recursive emulator for Wine Is Not a Emulator, from the fact it doesn't emulate a CPU. Therefore you cannot run x86 Windows programs on a PowerPC Macintosh.) OSx86 Wiki entry: http://wiki.osx86project.org/wiki/index.php/Darwine Darwine project page: http://darwine.opendarwin.org/

March 9, 2006

Re: WINED3D: Implement GetCreationParameters

by Francois Gouget

On Wed, 8 Mar 2006, Peter Beutner wrote: > Francois Gouget schrieb: >> * or the application does not pass a NULL here because it would cause >> it to crash on Windows. But if we merely return an error the application >> will merrily go on, only to crash or report that DirectX does not work a >> while later. By then the source of the problem will be very hard to find >> due to all that happened since this function call. >> The point is that we need to fix the bug that causes the application >> to pass a NULL to Wine in the first place. And the best way to spot it, >> and thus fix it, is if Wine segfaults in the same way as Windows when >> given a NULL. > The whole point of my email was that a crash here doesn't help you > to find the real problem. And you are wrong there. When an application crashes you have a very clear point where you know things went very wrong. This point is very clearly identified by the SEH traces and the winedbg backtrace. This information makes it *much* easier to find the original bug. And this is from experience. When an application doesn't crash but doesn't do what you want either, it's hard to even know which part of the log is relevant to the problem. > Imo a library is supposed to validate given parameters as much as > possible and rather return an error to the caller than to crash. No. A library can say that a given function must not be caled with a NULL parameter in which case it is perfectly valid to crash if that rule is violated. There's no point for both the callee and the caller to check for NULL parameters. > Let's just hope the kernel devs don't adopt your > "Better-crash-than-return-an-error" strategy :p The design of kernels, servers, and other pieces of code that have to deal with untrusted data (e.g. browsers), is completely different from that of general purpose libraries. Trying to apply the rules of one to the other will only give bad results. And, as was pointed out before, Wine is in yet a different situation since its number one requirement is compatibility with the Win32 API rather than breaking clean with it and 'doing things the right way' (whatever that is). -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Linux: the choice of a GNU generation

March 9, 2006

BF2 demo

by Ivan Gyurdiev

H. Verbeet wrote: > Currently pixel shaders get created, but not used. This patch enables > OpenGL fragment programs if pixel shaders are enabled and the harware > supports it. Makes fonts readable in the menu for the BF2 demo. This > patch should be applied after the one that removes the FIXME in > drawPrimitiveDrawStrided. > You were able to get the BF2 demo to show something? Is this with native d3dx9_25.dll ? Did you run into this bug at all? http://bugs.winehq.org/show_bug.cgi?id=4745

March 9, 2006

Re: fixme:commdlg:GetFileName95 Flags 0x00900000 not yet implemented

by Rainer Dorsch

Am Montag, 6. März 2006 09:34 schrieben Sie: > On Sunday 05 March 2006 21:50, you wrote: > > I went to 'Arbeitsplatz' in the Shell and then 'C'. MyDocuments was shown > > as a file, not a folder. I.e. the problem persists. > > I don't quite understand, since MyDocuments is on the Desktop, not on > 'Arbeitsplatz'. Could you please browse to 'Arbeitsplatz\C:\windows'? The hierarchy I see is Desktop->Arbeitsplatz->C:->windows > Just to be sure: In notepad the filedialog works fine, right? Yes, that works fine. Thanks, Rainer -- Rainer Dorsch Alzentalstr. 28 D-71083 Herrenberg 07032-919495 Icq: 32550367

March 8, 2006

Re: AlphaImageLoader - tranparent pngs 4 IE

by Adam Cooper

On Wed, 2006-03-08 at 11:02 -0500, Jason Green wrote: > On 3/8/06, Axel Huizinga <axel(a)3dragons.com> wrote: > > Did anybody get DXImageTransform.AlphaImageLoader working > > to render transparent png in IE on wine? > > If I recall correctly, transparent .PNG's don't even work in IE on > Windows (at least until the upcoming IE7.0). > With a bit of javascript wizardry and the aforementioned DXImageTransform you can get transparent pngs on IE. At least on a windows install of IE. I don't know if it works on wine. Regards Adam

March 8, 2006

Re: Trying to fix bug 2400 - delete and comma

by agaro

I know now what scancode, keycode and vkey are! :) Some references: * ScanCode and KeyCode http://lct.sourceforge.net/lct/x60.html http://www.tldp.org/HOWTO/Keyboard-and-Console-HOWTO-2.html http://www.win.tue.nl/~aeb/linux/kbd/scancodes-1.html * Virtual-Key Codes (vkey) http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/winu… I thought the problem was in TranslateMessage (dlls/user/message.c) and X11DRV_ToUnicodeEx (dlls/x11drv/keyboard.c) functions but I found others suspects: EVENT_event_to_vkey and X11DRV_InitKeyBoard (boths in dlls/x11drv/keyboard.c). What is happening? (in brazilian abnt2 keyboard with wine-0.9.9) The EVENT_event_to_vkey function return the wrong value 0x2E to X11DRV_KeyEvent which emits an event through X11DRV_send_keyboard_input. On MSDN and dlls/user/spy.c VK_SEPARATOR virtual key code apears as 0x6C, however in trace below apears as 0x2E while in both cases keycodes are equals. The 0x2E virtual key code value corresponds to VK_DELETE. My guess for now: X11DRV_InitKeyboard function initialize keyc2vkey array with wrong value for this case. Trace ($ WINEDEBUG=+key wine winecfg) of NumPad Delete key with NumLock key activated: trace:key:X11DRV_KeyEvent type 2, window a0000a, state 0x0010, keycode 0x005b trace:key:X11DRV_KeyEvent state = 10 nbyte = 1, status 0x4 trace:key:X11DRV_KeyEvent KeyPress : keysym=FFAC (KP_Separator), # of chars=1 / 0x2c / ',' trace:key:EVENT_event_to_vkey e->keycode = 5b trace:key:X11DRV_KeyEvent keycode 0x5b converted to vkey 0x2e trace:key:X11DRV_KeyEvent bScan = 0x53. trace:key:X11DRV_send_keyboard_input wParam=002e, lParam=00530001, InputKeyState=c1 trace:key:TranslateMessage Translating key VK_DELETE (002e), scancode 53 trace:key:GetKeyboardState (0x7faff024) trace:key:X11DRV_ToUnicodeEx (002E, 0053) : faked state = 0x0010 trace:key:EVENT_event_to_vkey e->keycode = 5b trace:key:X11DRV_ToUnicodeEx type 2, window a0000a, state 0x0010, keycode 0x005b trace:key:X11DRV_ToUnicodeEx Translating char 0x2c to unicode trace:key:X11DRV_ToUnicodeEx ToUnicode about to return 1 with char 2c trace:key:TranslateMessage 1 -> PostMessageW(0x10050,WM_CHAR,002c,00530001) trace:key:GetKeyState key (0x12) -> 0 trace:key:GetKeyState key (0x10) -> 0 trace:key:GetKeyState key (0x11) -> 0 trace:key:GetKeyState key (0x11) -> 0 trace:key:X11DRV_KeyEvent type 3, window a0000a, state 0x0010, keycode 0x005b trace:key:X11DRV_KeyEvent state = 10 nbyte = 0, status 0x1 trace:key:X11DRV_KeyEvent KeyRelease : keysym=0 (No Name), # of chars=0 / 0x00 / '' trace:key:EVENT_event_to_vkey e->keycode = 5b trace:key:X11DRV_KeyEvent keycode 0x5b converted to vkey 0x2e trace:key:X11DRV_KeyEvent bScan = 0x53. trace:key:X11DRV_send_keyboard_input wParam=002e, lParam=c0530001, InputKeyState=41 []s agaro

March 8, 2006

Re: WINED3D: Implement GetCreationParameters

by Alexandre Julliard

Peter Beutner <p.beutner(a)gmx.net> writes: > Just take the example you have written something in Office and the given behaviour(passing a > NULL pointer) happens when you click on the print button. If it crashes your work is lost, if > it returns an error( and the app handles it in a sane way ) you just won't be able to print > it, but may save it and print it somehow else. > In that case my main concern is certainly not that a crash helps me to find a bug, but > to don't loose my data ;) Your mistake is to assume that the app will handle the error in a sane way. That's extremely unlikely, especially for things like bad pointers since the app obviously didn't expect to be passing bad pointers. If the app really wants to handle that sort of error it can always add an exception handler around the call; so not trapping the error in the library doesn't prevent the app from catching the error, it just avoids forcing a lot of useless checks on well-written apps. And it's not clear at all that crashing is more likely to lose data than not crashing. With the Windows way, the app will merrily continue working with corrupt data, which gives it a lot more opportunities to add garbage to your data without noticing, than if it crashed right away before having done too much damage. -- Alexandre Julliard julliard(a)winehq.org

March 8, 2006

Re: WINED3D: Implement GetCreationParameters

by Peter Beutner

Hi Andreas Mohr schrieb: > Hi, > Can you mention an example of Windows popping up an error message "function > foo baz called with invalid parameter ..., what do you want me to do?". > See? Me neither... heh, the message will more likely looks like "Failed to initialize {Direct3D/DirectDraw/OpenGL/Foo}" Which still leaves you puzzled what the hell actually went wrong, but at least shows that sometimes the return values are actually checked for errors ;) > Any additional error checking in Wine that's *not done by Windows* to make > (semi-)abnormal code flow keep running is A Very Bad Thing (tm). So if a windows function crashes with a given set of parameters the aim is to exactly replicate that behaviour? hmm seems I have to re-think my argument I usually tell people that bugs in windows are not neccessarily also present in wine. Let's hope there is never a exploitable bug that needs to be implemented in wine :p >>> If there's a problem that we need to be aware of, then we'd better get to know >>> about it NOW, not 5 lines, not 3000 relay lines and not 10 minutes after it >>> occurred and nobody ever remembers what the actual problem was. >> To repeat it, if that crash happens you are *already* "3000 relay lines" after the actually >> problem and you have *no* clue what the actual problem is. > That may well be the case, but I sure as hell don't want to even increase > my trouble by orders of magnitude by waiting a lot longer in this error case... So let's remove the dozens of NULL pointer checks already in place ;) And better also the whole exception handling which gives applications the chance to carry on execution even in case of a segmentation fault, which highly increases the trouble to find the original source of the problem *scnr*.

March 8, 2006

Re: WINED3D: Implement GetCreationParameters

by Peter Beutner

Alexandre Julliard schrieb: > Peter Beutner <p.beutner(a)gmx.net> writes: > >> Or look at it from the view of a user developing a winelib application. I'm sure >> he will very much appreciate it when wine does a better parameter checking than MS >> and returns an error instead of a crash backtrace ;) >> Imo a library is supposed to validate given parameters as much as possible and >> rather return an error to the caller than to crash. > > It's just the opposite actually. A good library (which the MS ones > certainly aren't...) should crash on bad pointers, so that bugs can be > found and fixed. Hiding bugs and trying to stumble along is the MS > way, this is what leads to idiocy like having an exception handler in > lstrlen(). So if in this case Windows doesn't have a check we > certainly don't want one either. I fail to see in how far returning an error is hiding a bug. Imho if the library detects an error[*] it should pass the information to the application and let the application handle it. The library doesn't know if the application maybe can cope with it. Just ultimately crash is a bad idea imo. Just take the example you have written something in Office and the given behaviour(passing a NULL pointer) happens when you click on the print button. If it crashes your work is lost, if it returns an error( and the app handles it in a sane way ) you just won't be able to print it, but may save it and print it somehow else. In that case my main concern is certainly not that a crash helps me to find a bug, but to don't loose my data ;) [*] Obviously you can't check against every possible failure. And it certainly may be a bit too much to check against bad pointers in general, but a NULL pointer check is cheap, easy and certainly doable.

March 8, 2006

Re: AlphaImageLoader - tranparent pngs 4 IE

by Jason Green

On 3/8/06, Axel Huizinga <axel(a)3dragons.com> wrote: > Did anybody get DXImageTransform.AlphaImageLoader working > to render transparent png in IE on wine? If I recall correctly, transparent .PNG's don't even work in IE on Windows (at least until the upcoming IE7.0).

March 8, 2006

AlphaImageLoader - tranparent pngs 4 IE

by Axel Huizinga

Hi! Did anybody get DXImageTransform.AlphaImageLoader working to render transparent png in IE on wine? Cordially, Axel

March 8, 2006

Re: WINED3D: Implement GetCreationParameters

by Andreas Mohr

Hi, On Wed, Mar 08, 2006 at 03:49:55PM +0100, Peter Beutner wrote: > Hi > Andreas Mohr schrieb: > > We're not a library.We're a very, very, very, very specific piece of software > Well, I remember I was told that wine is just another gui toolkit like gtk+ or qt *scnr*. Good memory ;) However I didn't state that, and I wouldn't want to ;) > > that is required to absolutely, positively fully emulate Windows to the > > closest extent possible (within practical limits, of course). > > As such debating whether to delay a crash by adding useless checks > > *that do not exist in Windows*(!) to *work around* strange behaviour most > > likely caused by our own non-conformant code is utterly pointless. > And I thought the whole idea behind error-checking was not just to delay the crash > but to entirely prevent it and instead inform the user what and where something failed. > I would prefer it if the application pops up a message "xyz failed" rather than a crash. > (admittingly, in how far the application does this in a proper way is entirely out of > our hands ;) ) Can you mention an example of Windows popping up an error message "function foo baz called with invalid parameter ..., what do you want me to do?". See? Me neither... And how do you want to """prevent""" anything?? Forget it... > Let's just hope the kernel devs don't adopt your "Better-crash-than-return-an-error" strategy :p The kernel developers code according to their very own rules, they're the ones to design stuff properly and thus fully know error conditions and corner cases of the code they're designing from scratch. We *absolutely* don't - especially when considering MSDN "correctness" <expletive deleted>. Any additional error checking in Wine that's *not done by Windows* to make (semi-)abnormal code flow keep running is A Very Bad Thing (tm). > > If there's a problem that we need to be aware of, then we'd better get to know > > about it NOW, not 5 lines, not 3000 relay lines and not 10 minutes after it > > occurred and nobody ever remembers what the actual problem was. > To repeat it, if that crash happens you are *already* "3000 relay lines" after the actually > problem and you have *no* clue what the actual problem is. That may well be the case, but I sure as hell don't want to even increase my trouble by orders of magnitude by waiting a lot longer in this error case... Andreas Mohr

March 8, 2006

Re: WINED3D: Implement GetCreationParameters

by Peter Beutner

Hi Andreas Mohr schrieb: > On Wed, Mar 08, 2006 at 02:08:52PM +0100, Peter Beutner wrote: >> Imo a library is supposed to validate given parameters as much as possible and >> rather return an error to the caller than to crash. > We're not a library.We're a very, very, very, very specific piece of software Well, I remember I was told that wine is just another gui toolkit like gtk+ or qt *scnr*. > that is required to absolutely, positively fully emulate Windows to the > closest extent possible (within practical limits, of course). > As such debating whether to delay a crash by adding useless checks > *that do not exist in Windows*(!) to *work around* strange behaviour most > likely caused by our own non-conformant code is utterly pointless. And I thought the whole idea behind error-checking was not just to delay the crash but to entirely prevent it and instead inform the user what and where something failed. I would prefer it if the application pops up a message "xyz failed" rather than a crash. (admittingly, in how far the application does this in a proper way is entirely out of our hands ;) ) Let's just hope the kernel devs don't adopt your "Better-crash-than-return-an-error" strategy :p > If there's a problem that we need to be aware of, then we'd better get to know > about it NOW, not 5 lines, not 3000 relay lines and not 10 minutes after it > occurred and nobody ever remembers what the actual problem was. To repeat it, if that crash happens you are *already* "3000 relay lines" after the actually problem and you have *no* clue what the actual problem is.

March 8, 2006

Fwd: Can't run DirectX games on x86_64 biarch Linux

by Jason Green

On 3/8/06, Willie Sippel <willie(a)zeitgeistmedia.net> wrote: > [...] > I also build Wine on an amd64 system (running gentoo/ amd64), no problems. But > there's one thing I noticed a while ago: Wine continues to compile and > install even if some of the DLLs won't compile. I had this a few times in the > past, and ended up with a basically working Wine install that missed a few > DLLs, mostly OpenGL-related stuff. Maybe something like that happens to you? > Just check that all DLLs are built and in place, and make sure there were no > errors during compile (like I said, with some DLLs, Wine just continues to > build even though errors appear)... Correct, wine will compile and run without a lot of features and never warn you that they don't exist. See this wiki page for an example of what your include/config.h file should probably look like: http://wiki.winehq.org/Recommended_Packages I just added the Fedora Core 5 and Ubuntu Dapper sections yesterday, and I believe that they are at least 95% accurate, although I might have missed one somewhere. If someone can add the package names required for a gentoo build (or possibly create and maintain wine-cvs packages with all of the necessary deps???), it would probably help out many users trying to compile from source.

March 8, 2006