Hi Fernando,
first off, I am NOT an expert (in fact, I started on the MSCDEX
specs-reading only 3 days ago, because I wanted to code a CD-player
under DOS (in Pmode, but DOS nevertheless ;-))
I have to tackle the extra problem that I have to call the
function from PMODE and simulate the interrupt, but I am
already (finally) past that problem.
 > I debugged it, and found that when it doesn't work, it
 > seems that the name
 > it gets of the driver isn't correct, so when I try to
 > open the driver as a
 > file, I get a "file not found" error code.
I am just curious, but why do you do your communications
directly via the driver? You don't need the driver-handle
to communicate with a CD-ROM ... only its drive number :-)
since you use the MSCDEX, I think you can look up the
function 01510h of int 02Fh ... it does the same thing
as providing IOCTL I/O with the driver (amongst other
things) ... if you don't have the MSCDEX (2.x) specs,
I can send them to you (if you have email)
 > The name it gets under MS-DOS is different from the
 > one that it gets under
 > W'95, but it should work anyway, I think....
I am just guessing (since I don't know much about
WIn'95 programming), but I think the driver-name (8 byte
field) ie the 'device' name isn't at the same offset
when using Win'95 and its 32bit drivers. So that's
why the int 21h / Open Existing File or Device doesn't
work.
 > Another fact, all the programs (well, except one from
 > Tenie Remmel's
 > snippets that doesn't use this "technique") have the
 > same "bug" as my
 > program...
don't use int 21h to communicate with the drive.
After having detected MSCDEX (int 2fh, fct 1100h, sub 0DADAh)
ask for the number of drives and the first drive number
(int 2fh, fct 1500h) ... then use a number relative
to the first drive (smaller than the number of drives)
to acces that CD-ROM via a similar IOCTL-call (with
int 2fh, fct 1510h)
 > I have really no idea about what could be happening...
 > :(
My guess is the above (since I have made a small PASCAL
programm that ejects the tray (just to test)), and it
worked fine under DOS as well as Win'95 (also when I
hadn't loaded MSCDEX.EXE)
besides, I suspect that since it is an Progr. Interface
(int 2fh, fct 15xxh), it is likely that Win'95 drivers
must obey in a same way, with the same interface.
So don't call for the handle and then use int 21h fct 44xxh,
but instead do the above. ...
Here is the PASCAL prog (not really a clean example, since
I whipped it up as a RM example and test case for inside
W'95) ... sorry to all for pascal-code, but I am not able
to make a full asm prog (I only use asm to optimise or
in this case: do something in a specific and defined,
hence 'do-it-like-that-or-else' way)
-*-
TYPE transfer = record
                   command : byte;
                end;
     reqhdrioctl = record
                 hsize, subunit, command: byte;
                 status : word;
                 reserved : array[0..7] of byte;
                 mediadesc : byte;
                 t : ^transfer;
                 tnr : word;
                 startsect : word;
                 pIDfunc : longint;
     end;
VAR b: reqhdrioclt;
    t : transfer;
CONST eject: byte = 0;
      drivenr = 4;  { change this to the drivenr of your CD-ROM
                      0 = A:, 1 = B:, 2 = C: ... 25 = Z:}
BEGIN
   b.hsize := 26;
   b.command := 12;
   b.subunit := 0;
   b.t := addr(t);
   t.command := eject;
   b.mediadesc := 0;
   b.tnr := 1;
   b.startsect := 0;
   b.pIDfunc := 0;
   ASM
      mov ax, ds
      mov es, ax
      mov ax, $1510
      mov bx, offset b
      mov cx, drivenr;
      int 2fh
   END;
END.
 > e-mail: FGont@siscor.bibnal.edu.ar
if you don't have it, drop me a note, and I'll send the specs
to this addres via a mime-attached zip-file.
Greetz,
Da Gongo
--- FMail/386 1.02
---------------