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
Petr Tesarik hat@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.
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@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@winehq.org
Petr Tesarik hat@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:
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.
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 -
Petr Tesarik