Re: [PATCH 1/3] winedos: better MSCDEX emulation

[Petr Tesarik]

Hi everyone,

has this patch been rejected?  If so, could anyone tell me why?

Yes, I know that neither the API, nor the include files are ideal yet,
but fixing it would produce a really huge patch, which is AFAIK
something you don't like at all.

Anyway, with this patch and my other patches applied (including one to
the Linux kernel, which was accepted in 2.6.15), I can now run Kindler
Literaturlexikon with Wine.  And I'd enjoy adding that application to
the appdb.

Petr

Dne 03/31/06 v 14:29:38 (+0200), Petr Tesarik napsal(a):
> Hi,
>
> while I was trying to make Kindler Literaturlexikon work in Wine, I
> found out that this program uses a DOS program to access the CDROM,
> and that it requires a real working MSCDEX device driver (and not only
> that, the driver has to reside in a different segment than the DOS
> core).
>
> To make the patches as small as possible, I've split the patch into
> several parts.
>
> This part just moves some declarations from devices.c to dosexe.h, so
> that the code in devices.c can be used from other source files.
>
> ChangeLog:
>
> * dlls/winedos/devices.c, dlls/winedos/dosexe.h:
> winedos: move some declarations to the header file

[PATCH 1/3] winedos: better MSCDEX emulation

[Alexandre Julliard]

Petr Tesarik <hat(a)tesarici.cz> writes:
> Hi everyone,
>
> has this patch been rejected?  If so, could anyone tell me why?

The 1/3 patch is OK, but I'd appreciate if you could split the 3/3 one
so I can get a better idea of where you are going with all this.

-- 
Alexandre Julliard
julliard(a)winehq.org

[PATCH 1/3] winedos: better MSCDEX emulation

[Petr Tesarik]

Hi,

OK, what I'm trying to do is provide a real DOS device driver for DOS
MZ programs, so that they can call the "strategy" routine to set the
address of device requests and then the "interrupt" routine to do the
actual requests (see just about any DOS programming guide for
details).

That means I have to:

  1. move the code for INT2F/AX=1510h (SEND CD-ROM DEVICE DRIVER
     REQUEST) to the interrupt routine

  2. provide a strategy routine

  3. get the device driver registered in DOS structures (add it to the
     end of the linked list of device drivers, which starts by the NUL
     driver in the List-of-Lists).

Now, I've found some (minor) bugs in the device driver code, and I
fixed them along the way. IMO what you need is that:

  1. First, I send a patch that moves the (buggy) code to a separate
     function which can be called both by the INT2F handler and by the
     interrupt routine.

  2. Next, I send a patch fixing the bugs.

Is that right?

Petr Tesarik

On 04/07/06 at 14:53:34 (+0200), Alexandre Julliard wrote:
> Petr Tesarik <hat(a)tesarici.cz> writes:
> > Hi everyone,
> >
> > has this patch been rejected?  If so, could anyone tell me why?
>
> The 1/3 patch is OK, but I'd appreciate if you could split the 3/3 one
> so I can get a better idea of where you are going with all this.
>
> -- 
> Alexandre Julliard
> julliard(a)winehq.org

[PATCH 1/3] winedos: better MSCDEX emulation

[Alexandre Julliard]

Petr Tesarik <hat(a)tesarici.cz> writes:
> Now, I've found some (minor) bugs in the device driver code, and I
> fixed them along the way. IMO what you need is that:
>
> 1. First, I send a patch that moves the (buggy) code to a separate
>      function which can be called both by the INT2F handler and by the
>      interrupt routine.
>
> 2. Next, I send a patch fixing the bugs.
>
> Is that right?

Yes, each separate change must be a separate patch. If you are moving
code, you should send a patch that does just that, without changing
anything else. If you are fixing bugs send one patch per bug.

-- 
Alexandre Julliard
julliard(a)winehq.org