April 2010 - Wine-Devel - list.winehq.org

Re: [PATCH 5/5] Rename color_fixup_supported to blit_supported support and add additional checks.

by Henri Verbeet

On 1 April 2010 23:58, Roderick Colenbrander <thunderbird2k(a)gmail.com> wrote: > + /* In general we don't support any destination fixups except for P8. P8 fixup > + * can occur in three cases: > + * 1) Blit from p8 source to p8 destination, this is a source fixup and the > + * destination fixup can be ignored. > + * 2) LockRect on surface, LoadLocation takes care of the 'destination fixup'. > + * 3) RealizePalette refreshes the palette of a surface. The surface is then > + * both the source (the sysmem / texture copy) and the destination (drawable). > + * But you don't know all that. All you know is that you've got two surfaces with certain properties. You could argue that since the source and destination fixups are the same they cancel out, so that you can do that blit as long as you either don't stretch or the fixup is linear. However, in that case you also need to make sure the blitter actually behaves like that.

April 2, 2010

Re: [PATCH 3/5] Move palette uploading code over to arbfp blit_shader.

by Henri Verbeet

On 1 April 2010 23:58, Roderick Colenbrander <thunderbird2k(a)gmail.com> wrote: > > +static void upload_palette(IWineD3DSurfaceImpl *surface) > +{ > + BYTE table[256][4]; > + IWineD3DDeviceImpl *device = surface->resource.device; > + BOOL colorkey = (surface->CKeyFlags & WINEDDSD_CKSRCBLT) ? TRUE : FALSE; > + > + d3dfmt_p8_init_palette(surface, table, colorkey); If that's really what you want, you need to add this function to wined3d_private.h. Right now it will generate a warning. Perhaps it should just be in surface.c though? This function depends on having an active context. Where is "palette_texture" deleted?

April 2, 2010

Re: Working on "DOS" VGA.

by Damjan Jovanovic

On Thu, Apr 1, 2010 at 8:20 PM, Saulius Krasuckas <saulius2(a)ar.fi.lt> wrote: > * On Thu, 1 Apr 2010, Stefan Dösinger wrote: >> Am 01.04.2010 um 11:24 schrieb Roderick Colenbrander: >> >> > Myself I'm a bit worried about whether we should improve our DOS >> > support even further. The problem is that more and more people are >> > moving over to 64-bit Linux. While you can run 32-bit programs on a >> > 64-bit system, there is no protected mode support (vm86; there is >> > emulation in some cases using a kernel module). >> >> There's protected mode 32 bit, protected mode 16 bit, but no vm86 16 >> bit. So no real mode apps in Wine. We'd need to integrate a CPU emulator >> or JIT compiler into Wine to get this working. > > DOSBox does something like this already. I lack ideas about to what > extent DOSBox could be integrated, but at least its CPU emulator could do. > Or maybe DOSBox could even be bridged/integrated and do all the DOS stuff > here? > > Then IIRC there were discussions in the past about integrating Qemu into > Wine. Some folks at Darwine have achieved this to some degree: [1] > > That probably won't fly directly [2] but some aspects of the design of an > emulator integration can be investigated already, IMHO. > > > S. > > [1] http://darwine.sourceforge.net/docs/dev-doc.xml > [2] http://wiki.winehq.org/FAQ#head-5804ec2bb090feaf81f572993444efd8ec2a8569 > > > AFAIK we can't integrate with DOSBox, Dosemu or FreeDOS for the same reason we can't integrate with Samba: their GPL licence. QEMU's CPU core library however is LGPL (http://wiki.qemu.org/License) just like Wine - but in my experience QEMU is very slow when it does full emulation. Damjan

April 2, 2010

re: [PATCH 0/4] Unwinding the stack with Dwarf (CFA) information on i386

by Dan Kegel

Eric wrote: > With this patch set, one can get rid of most of the non visible parameters values > while using a backtrace in winedbg. That's great news, thanks, hope it goes in soon!

April 2, 2010

Re: [PATCH 2/2] Revert prev. Hack, as Bug 10000 is still present.

by James McKenzie

John Klehm wrote: > On Thu, Apr 1, 2010 at 11:16 AM, Detlef Riekenberg <wine.dev(a)web.de> wrote: > >> With greeting from the current day. >> >> > > hehe nice > > Like the part about world domination. However, that will have to wait for Linux/MacOSX to be the OS of choice. :) James McKenzie

April 2, 2010

Re: Working on "DOS" VGA.

by chris ahrendt

Just my 2 phennings worth on this... Why reinvent the wheel... I would say instead of doing the emulator inside wine... or a JIT... why not have wine intersept the call to start the vm86 mode.. and forks off and starts DOSEMU or whatever DOS box system is configured.. That way wine doesnt have to worry about it... chris

April 2, 2010

Re: winmm: For MCI parsing, use 64bit compatible structures.

by Eric Pouech

Joerg-Cyril.Hoehle(a)t-systems.com a écrit : > Hi, > > Eric Pouech wrote: > >> this patch is ugly as hell... >> > Please qualify. To me, > - data[3] = (DWORD_PTR)dev; > + parms.open.lpstrElementName = dev; > looks more robust than before: > - no magic offsets, > - no casts that may silence warnings. > actually there are not magic offsets, but can be computed from the previous values written. the current parser can be better rewritten in a way were fields are written to in sequential order (currently, for example, return values are written at the end, which is not satisfactory) but I agree current that current parser can be improved >> and it still believe we can do the MCI >> parser without knowing about MCI structures internals >> > What do you mean? > Quite to the contrary, the parser depends on knowing the internals > of some commands (like MCI_OPEN) as well as the convention about the > return value as 2nd (+3rd) slot after the callback. > MCI_OPEN is kinda specific the others are not. it just uses that first parameter is callback, second is the returned type (which is described in the MCI table), then parameters, which are also described in the table. no nothing magic here > The parser bridges the gap between the resource definition files > winmm_res.rc that are now in git and are known to work well with > 32bit and the mixed DWORD/DWORD_PTR MCI_..._PARMS definitions whose > correctness has been (partially) validated by tests. > to me what works are test (and packing) of MCI structures on 64 windows (but with native DLLs, hence using native MCI tables) what doesn't work is MCI parser (with builtin winmm) and same MCI structures but we never validated builtin MCI tables on windows... > What we don't know is whether Win64 introduced a different winmm_res.rc. > I'd sure would be pleased if somebody could describe whether there > have been changes to the resources to accommodate 64bit pointers in MS-Windows. > we just need a copy of 64bit winmm.dll. If someone could mail it to me privately, it would be rather easy to check. A+ -- Eric Pouech "The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot." (Douglas Adams)

April 1, 2010

Re: [PATCH 1/5] winmm: Improve MCI's Sysinfo command.

by Eric Pouech

Joerg-Cyril.Hoehle(a)t-systems.com a écrit : > Hi, > > Eric Pouech wrote: > >> did you test the 16 => 32 bit conversion for the MCI_ALL_DEVICE ? >> > > It's good you asked. Upon closer inspection, MCI_Sysinfo appears to > behave differently. I'd say it's even a bug in MS that setting > SYSINFO_PARMS.wDeviceType = MCI_ALL_DEVICE_ID is not recognized! Only > sendCommand(MCI_ALL_DEVICE_ID, MCI_SYSINFO ...) appears usable to > obtain the functionality of "sysinfo all ..." :-( > > I'll supersede the patch ASAP. > Grr, that's not going to simplify the parser. > > Regards, > Jögr Höhle > > > > > but does SYSINFO_PARMS.wDeviceType = (WORD)(DWORD)MCI_ALL_DEVICE_ID; work better ? if yes, I'd be convinced for a bug in native winmm, missing a (WORD) cast somewhere... A+ -- Eric Pouech "The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot." (Douglas Adams)

April 1, 2010

Re: [PATCH 1/5] winmm: Improve MCI's Sysinfo command.

by Eric Pouech

Joerg-Cyril.Hoehle(a)t-systems.com a écrit : > Hi, > > Eric Pouech wrote: > >> did you test the 16 => 32 bit conversion for the MCI_ALL_DEVICE ? >> > > Which ones do you have in mind? There are tests involving MCI_ALL_DEVICE_ID > that pass on both win9x and later (also in patch #5). I wrote a few > more MCI tests privately. Generally, I added (UINT16) casts in Wine > when I saw test failures on Win9x platforms, then kept doing so (i.e. > I'm not sure I've tested SYSINFO with a 0000FFFF deviceID on Win9x in > particular or whether I simply use that pattern everywhere now after > having been burnt once). There are a few patches already in > git that fix a few MCI_ALL_DEVICE_ID here and there, but as you wrote > yourself in the TODO header long ago, support for it is incomplete. > Making "close all", "play all" etc. work is on my private TODO list, but > I never started working on this particular item. > > >> actually, I'd say it belongs to the 16=>32 mci message mapper, not in >> generic 32bit code >> > Do you mean dlls/mmsystem.dll16? I never looked at it but I > don't think that's the correct place, see below. > Do you mean the A/W (un)mapping? That's distinct, because it deals > with string conversions only, as the name suggests, and it does > not mogrify dwParam1. > > Current test results suggest that MCI_ALL_DEVICE_ID is not only a 16/32 > issue -- at least when I equate 16 with MS-Windows 3.x -- Have a look > at the mciGetDeviceID("all") test case, which returns a 16bit FFFF on Win9x, > not FFFFFFFF. Therefore I believe Wine must be prepared for receiving > 0000FFFF as ALL_ID from old Win9X apps or drivers -- possibly regardless > of them using the A or W function entry points. > that's the point I wanted to be clarified did you check what mciGetDeviceID("all") returns on Vista or XP ? if it's 0xFFFF in all cases, the real answer is then that device ID are internally UINT16 and we shouldn't care at all about 32 bit extension it it's 0xFFFFFFFF in latest windows, then likely the device ID has been extended internally, and we should cope with both 0xFFFF and 0xFFFFFFFF values in winmm -- Eric Pouech "The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot." (Douglas Adams)

April 1, 2010

Re: Working on "DOS" VGA.

by Saulius Krasuckas

* On Thu, 1 Apr 2010, Stefan Dösinger wrote: > Am 01.04.2010 um 11:24 schrieb Roderick Colenbrander: > > > Myself I'm a bit worried about whether we should improve our DOS > > support even further. The problem is that more and more people are > > moving over to 64-bit Linux. While you can run 32-bit programs on a > > 64-bit system, there is no protected mode support (vm86; there is > > emulation in some cases using a kernel module). > > There's protected mode 32 bit, protected mode 16 bit, but no vm86 16 > bit. So no real mode apps in Wine. We'd need to integrate a CPU emulator > or JIT compiler into Wine to get this working. DOSBox does something like this already. I lack ideas about to what extent DOSBox could be integrated, but at least its CPU emulator could do. Or maybe DOSBox could even be bridged/integrated and do all the DOS stuff here? Then IIRC there were discussions in the past about integrating Qemu into Wine. Some folks at Darwine have achieved this to some degree: [1] That probably won't fly directly [2] but some aspects of the design of an emulator integration can be investigated already, IMHO. S. [1] http://darwine.sourceforge.net/docs/dev-doc.xml [2] http://wiki.winehq.org/FAQ#head-5804ec2bb090feaf81f572993444efd8ec2a8569

April 1, 2010