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

Re: Working on "DOS" VGA.

by Stefan Dösinger

Am 02.04.2010 um 02:08 schrieb 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... Because you can mix modes in one executable. Take for example the average modern dos game: They start as real mode apps, then switch to a 32 bit protected mode dos extender(e.g. dos4gw.exe). I wouldn't be surprised if the app can transform itself into a Win16 app that tries to pop up a window. Wouldn't work well in Linux dosemu. What may work better however is using a Win32 dosemu binary to load the app. Then we just have to make sure that windows dosemu can deal with such mixed apps.

April 2, 2010

Re: A possible way to fix cygwin issue

by Alexandre Julliard

GOUJON Alexandre <ale.goujon(a)gmail.com> writes: > Hi, > > I'm just wondering if this approach may solve the issue. > I'm maybe totally wrong but there's no harm in trying... You don't want a W->A->W conversion for the command line, that's why these programs are Unicode in the first place. -- Alexandre Julliard julliard(a)winehq.org

April 2, 2010

Re: winedump: code cleanup

by Mikhail Maroukhine

oops. Absolutely agree. Thanks for the comment. Will fix it. Thanks, Mikhail On Fri, 02 Apr 2010 00:29:16 +0700, Alexandre Julliard <julliard(a)winehq.org> wrote: > "Mikhail Maroukhine" <mikolg(a)yandex.ru> writes: > >> Hello, >> >> Could you clear a little what do you mean under "stop abusing"? >> I've removed incorrect usage of constness in declaration for the >> variable that is changed for sure. >> I've send "try 2" patch with additional correction and extended log >> message. > > I mean your new origProtoRef variable (which BTW uses a completely > different naming convention from the rest of the function) to work > around the fact that the argument is modified. Much better to use a > properly named local variable to store results and not modify the > argument. > -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

April 2, 2010

A possible way to fix cygwin issue

by GOUJON Alexandre

Hi, I'm just wondering if this approach may solve the issue. I'm maybe totally wrong but there's no harm in trying...

April 2, 2010

MicroOLAP Database Designer for PostgreSQL

by Tom Wickline

This might be considered spam but I thought I would share it. MicroOLAP Database Designer for PostgreSQL with enhanced WineHQ support released. MicroOLAP Database Designer for PostgreSQL is an easy CASE tool with intuitive graphical interface allowing you to build a clear and effective database structure visually, see the complete picture (diagram) representing all the tables, references between them, views, stored procedures and other objects. Then you can easily generate a physical database on a server, modify it according to any changes you made to the diagram using fast ALTER statements. http://www.wine-reviews.net/wine-reviews/news/microolap-database-designer-f… Cheers, Tom

April 2, 2010

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

by Henri Verbeet

On 2 April 2010 13:49, Roderick Colenbrander <thunderbird2k(a)gmail.com> wrote: > This was a long mail (hope you can make sense of it). To summarize the > P8 check in blit_supported is so ugly (and it might not work in all > cases) for a part due to CheckSurfaceCapability and CheckDeviceFormat. > I think that if I would kill the P8 texture support it might take away > your concerns. While I would like to keep the problem as simple as > possible I fear that some parts of d3dfmt_get_conv already need a > rewrite at this point since it is starting to make life difficult. The > main concern is how to perform surface conversion when needed and the > color keying (though for that a special location flag could work as > you suggested before). > Can't you handle P8 -> P8 blits as regular ARGB -> ARGB blits as long as you don't stretch? I.e., compared to this patch the main difference would be that you don't set the P8 -> ARGB shader at all in that case. This would be generic for all complex fixups as long as we don't stretch, and for simple / linear fixups even with stretching. Only slightly related, I think it's reasonable to require non-NULL source / destination rectangles for internal interfaces. I.e., handle NULL rectangles in the public wined3d entry points, but just require them to be non-NULL everywhere else.

April 2, 2010

Re: Working on "DOS" VGA.

by Johan Gill

On Fri, Apr 2, 2010 at 1:42 PM, Saulius Krasuckas <saulius2(a)ar.fi.lt> wrote: > * On Fri, 2 Apr 2010, Damjan Jovanovic wrote: >> 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: >> >> >> >> 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] >> >> AFAIK we can't integrate with DOSBox, Dosemu or FreeDOS for the same >> reason we can't integrate with Samba: their GPL licence. > > I am profane at licensing, but does GPL restrict even usage of binary > (linking, execution), or only a compilation of source code? > I'm not a lawyer, but my understanding of the license is that you cannot in general link to GPL code without making the whole binary fall under GPL. The LGPL allows a program to link to it without affecting the license of the program, though. You can however have your non-GPL code execute a separate GPL binary without affecting the legal state of your own code. The important part is that the programs are kept separate. /Johan Gill

April 2, 2010

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

by Roderick Colenbrander

On Fri, Apr 2, 2010 at 12:15 PM, Henri Verbeet <hverbeet(a)gmail.com> wrote: > 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. > I must say that I'm not happy with the piece of code myself. The problem is that the P8 code has more or less behaved like this the past couple of years and yes that was bad and I don't think all ugliness can be fixed one step. The check in blt_supported is not so great and I'm not sure if it can be improved well. If blit_supported had access to the source and destination surface, it could just check if they are the same which would handle the needs of corner cases like RealizePalette and LoadLocation. RealizePalette doesn't really care about whether a blit is supported at all, it just wants to know if p8 conversion is done by the gpu, so it can call LoadLocation texture->drawable else LoadLocation is called to perform a sysmem->(surface_conversion texture->) drawable upload. The callers (LoadLocation) do care, since they have to perform conversion or not (it is fun how the conversion is entangled with the blit_shader). The main reason for not passing surfaces to blit_supported was because of CheckSurfaceCapability and CheckDeviceFormat which don't have access to them and need a sort 'color_fixup_supported'. Perhaps we should have two calls one which works on pools/flags and one which works on surfaces (and which just extracts the info and passes it to the other one)? Another slightly related issue is d3dfmt_get_conv. Right now it loads format info from the formats_table. The formats table contains opengl extension checks and based on this sets the formats for the arbfp p8 shader or the ffp paletted_texture code. Perhaps we should ask the blit_shader (once you know that it supports a certain blit) about the format. and so now and then afor P8_UINT. The blit_shader can fall back to d3dfmt_get_conv (or the formats table) when it doesn't perform an override. The same could be done for color keying but the main issue is that you don't know for what purpose you arrived in LoadLocation, so asking the blit_shader won't make sense all cases. > However, in that case you also need to make sure the > blitter actually behaves like that. Even before the ongoing rewrites this is basically how the P8 code behaved. At some point the yuv fixups were added and then FIXMEs about destination fixups appeared because the p8 code didn't receive a rewrite yet. The blit_supported code works fine for p8 source -> p8 render_target while the p8 framebuffer -> texture path is quite broken (I'm quite sure the fb_copy_ ones don't work; not sure about FBO; read_from_framebuffer works though). But I think the framebuffer -> texture code should be killed since I don't think we should advertise P8 textures at all. This would only leave p8 source -> p8 render_target destination fixups and LoadLocation. This was a long mail (hope you can make sense of it). To summarize the P8 check in blit_supported is so ugly (and it might not work in all cases) for a part due to CheckSurfaceCapability and CheckDeviceFormat. I think that if I would kill the P8 texture support it might take away your concerns. While I would like to keep the problem as simple as possible I fear that some parts of d3dfmt_get_conv already need a rewrite at this point since it is starting to make life difficult. The main concern is how to perform surface conversion when needed and the color keying (though for that a special location flag could work as you suggested before). Roderick

April 2, 2010

Re: Working on "DOS" VGA.

by Saulius Krasuckas

* On Fri, 2 Apr 2010, Damjan Jovanovic wrote: > 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: > >> > >> 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] > > AFAIK we can't integrate with DOSBox, Dosemu or FreeDOS for the same > reason we can't integrate with Samba: their GPL licence. I am profane at licensing, but does GPL restrict even usage of binary (linking, execution), or only a compilation of source code? > in my experience QEMU is very slow when it does full emulation. Should not be slower that eg. BOCHS. S.

April 2, 2010

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

by Henri Verbeet

On 2 April 2010 12:19, Roderick Colenbrander <thunderbird2k(a)gmail.com> wrote: > +void d3dfmt_p8_init_palette(IWineD3DSurfaceImpl *This, BYTE table[256][4], BOOL colorkey); That function is internal to wined3d.

April 2, 2010