INT 2F 112E (IFS extended open) arguments confusion ...
R.Wieser
I'm trying to make sense of the arguments to the INT 2F, AX=112Eh -call,
and am currently confused.
Ralf Browns famous list shows, next to the filename itself and a pointer to
the unopened SFT, 3 arguments that rule how the file is opened/created : one
argument on the stack and two in the SDA, being action-code and open mode.
For some reason I get the feeling that the high-byte of the
argument-on-stack (low-byte is attributes) tells me what the action-code in
the SDA allready tells me in it's upper nibble ...
Or does it ?
Can someone tell me what the difference between the two is (if any) and if I
can maybe just disregard that high-byte of the argument-on-stack ?
Regards,
Rudy Wieser
P.s.
I did allso follow Ralf Browns link to INT 21h, AX=6C00h . Alas, it did not
clarify anything for me.
Rod Pemberton
"R.Wieser" <add...@not.available> wrote in message
news:43c582bf$0$11070$e4fe...@news.xs4all.nl...
I'm not sure, and could be completely off base... But, I suspect that you
need to tell it how you want the file open twice.
1) simply, with the STACK word
2) "extendedly," with the SDA action code.
It is an _extended_ open/create after all... ,)
As a side note, how are things going with the network redir?
Found some useful stuff for you in OpenDOS/DR-DOS 7.02:
REDIR.EQU has the defines for the supported 2F functions.
REDIR.ASM has INT 2F code.
Also, these have some too: DISK.ASM, CIO.A86, DISK,A86, MISC.A86,
PROCESS.A86, NETWORK.A86, INT2F.A86
DR-DOS 7.02 source here:
ftp://ftp.fsn.hu/pub/OpenDOS/
Udo Kuhnt's "DR-DOS enhancement project"
http://www.drdosprojects.de/
From REDIR.EQU, you'll see DR-DOS doesn't support functions above 1126. :(
; Int 2F AH=11 msnet redirector hook equates
I2F_PRESCENCE equ 1100h
I2F_RMDIR equ 1101h
I2F_MKDIR equ 1103h
I2F_CHDIR equ 1105h
I2F_CLOSE equ 1106h
I2F_COMMIT equ 1107h
I2F_READ equ 1108h
I2F_WRITE equ 1109h
I2F_LOCK equ 110Ah
I2F_UNLOCK equ 110Bh
I2F_SPACE equ 110Ch
I2F_SET_ATTR equ 110Eh
I2F_GET_ATTR equ 110Fh
I2F_REN equ 1111h
I2F_DEL equ 1113h
I2F_OPEN equ 1116h
I2F_CREATE equ 1117h
I2F_XCREATE equ 1118h
I2F_XSFIRST equ 1119h
I2F_SFIRST equ 111Bh
I2F_SNEXT equ 111Ch
I2F_PCLOSE equ 111Dh
I2F_REDIR_5F equ 111Eh
I2F_REDIR_5E equ 111Fh
I2F_FLUSH equ 1120h
I2F_LSEEK equ 1121h
I2F_PTERM equ 1122h
I2F_PPATH equ 1123h
I2F_CTLP_ERR equ 1124h
I2F_REDIR_5D equ 1125h
I2F_CTLP equ 1126h
Rod Pemberton
R.Wieser
b6ph93-...@news.infowest.com...
Hello Rod,
First of all, thanks for the DR-DOS links. Alas, when I took a peek I could
only find disk-images, bootdisk-files, licences, etc, but no sources. A
quick search on the net for redir.asm & redir.equ did not turn up anything
either ...
> I'm not sure, and could be completely off base... But, I suspect
> that you need to tell it how you want the file open twice.
Not quite. I first need to know how to open a file *at all* :-)
> As a side note, how are things going with the network redir?
Actually, that is why I asked. As something else grabbed my attention I
suspended that project for a while, and have just last week taken it up
again.
My previous version was able to do a directory-listing, and copy a file from
the remote machine, albeit on a direct (very silent) connection : it
could not handle non-received packets.
After re-writing that so it would re-send request after a 3 second delay for
upto 3 times I again tried to make sense of that extended-open call
(2F,112E).
The problem is that the DOS-kernel does not seem to be calling it with
values I can find in Ralfs Browns Interrupt-list or can make sense of
myself.
When I'm trying to open a file to copy from I see, as data-on-stack
(attributes & create-flag), SDA-action and SDA-mode 0040h,40h, 0040h, and
only the middle one makes sense to me. 40h for attribute ? and 40h for
action ? That seems to indicate that whatever is done, it should *allways*
fail. I can ofcourse assume that when there is a "fail allways"
combination present that I should just try to open the file, but that is not
mentioned anywhere (not with 2F, 112E nor with 21,6C00)
When I try to copy something *to* the remote drive I see 0020h, 40h, 0021h.
That's a lot better, but now I'm missing the create-the-file flag in the
high-byte of the first value ....
Confusing to say the least.
I'm think I will just ignore all but the low 6 bits of the first and last
values (attributes & SDA-mode), and see how far can I get.
Regards,
Rudy Wieser
P.s.
Not quite knowing what should be placed where in the SFT for the file does
allso not really help : it worked o.k. for opening the file, but it fails
when trying to create one. Oh, well. More to look at (I'll just compare
SFT's of opened and freshly created files and see if I can spot the
difference)
Rod Pemberton
"R.Wieser" <add...@not.available> wrote in message
> Rod Pemberton <dont...@bitbucket.cmm> schreef in berichtnieuws
> b6ph93-...@news.infowest.com...
>
> Hello Rod,
>
> First of all, thanks for the DR-DOS links. Alas, when I took a peek I
could
> only find disk-images, bootdisk-files, licences, etc, but no sources. A
> quick search on the net for redir.asm & redir.equ did not turn up anything
> either ...
Doh! Sorry, I didn't realize the sources weren't there. They are available
as the first link on Udo's dowload page:
http://www.drdosprojects.de/cgi-bin/download.cgi/dossrc.zip
> When I'm trying to open a file to copy from I see, as data-on-stack
> (attributes & create-flag), SDA-action and SDA-mode 0040h,40h, 0040h, and
> only the middle one makes sense to me. 40h for attribute ? and 40h for
> action ? That seems to indicate that whatever is done, it should
*allways*
> fail. I can ofcourse assume that when there is a "fail allways"
> combination present that I should just try to open the file, but that is
not
> mentioned anywhere (not with 2F, 112E nor with 21,6C00)
>
> When I try to copy something *to* the remote drive I see 0020h, 40h,
0021h.
> That's a lot better, but now I'm missing the create-the-file flag in the
> high-byte of the first value ....
That would be tables #01401, #01770, & #01769 respectively?
40h - that has only bit6 set, which isn't in any of those tables...
Well, you've got my two worthless bits. Let's hope someone else helps.
Rod Pemberton
R.Wieser
Hello Rod,
> They are available as the first link on Udo's dowload page:
And now it's my turn to say Doh! Twice. I though I had checked that
download-page. And a second time for realizing that I've got a(n older)
copy of that archive sitting in my "Assembly stuff to check out" folder ....
> > I see, as data-on-stack (attributes & create-flag),
> > SDA-action and SDA-mode 0040h,40h, 0040h,
<snip>
> That would be tables #01401, #01770, & #01769 respectively?
> 40h - that has only bit6 set, which isn't in any of those tables...
1769 and 1401 seem to be the same tables, but yes, 1770 and 1769 are two of
them ... And yes, those values not being mentioned there is exactly what is
confusing me .... :-)
> Well, you've got my two worthless bits. Let's hope someone else helps.
You gave me a few tid-bits and an URL, so you sure did help.
But that does not mean I would not be gratefull for someone who can explain
(or point me to a page where iI can read it) how those INT 2Fh, AX=112Eh
arguments are linked to the SFT. Or how the INT 21h, AX=6C00h arguments are
linked/translated to those of INT 2Fh, AX=112Eh. :-)
Thanks again for your help.
Regards,
Rudy Wieser
Rod Pemberton
"R.Wieser" <add...@not.available> wrote in message
> Rod Pemberton <dont...@bitbucket.cmm> schreef in berichtnieuws
> klpi93-...@news.infowest.com...
>
<snip>
What made you decide to use 112e? Is it being triggered from DOS? I'm
wondering because I only see three redirector functions in RB's interrupt
list that say "DOS 4.0+". The other _seventeen_ or so DOS 4 redirector
functions say "DOS 4.x only". Perhaps they made a mistake?
Rod Pemberton
R.Wieser
Hello Rod,
> What made you decide to use 112e? Is it being triggered
> from DOS? I'm wondering because I only see three
> redirector functions in RB's interrupt list that say
> "DOS 4.0+". The other _seventeen_ or so DOS 4
> redirector functions say "DOS 4.x only". Perhaps
> they made a mistake?
Actually, that choice was made for me. I just wedged INT 2Fh, AH=11h and
looked at which calls floated by. 112E is one of them. Not catching it in
my program does not prompt DOS to use a simpler one, so I was stuck on using
it.
As for that they perhaps made a mistake ? I really would not know.
Currently I just look at which INT 2Fh, AH=11h calls DOS does and cannot
resolve itself, and than write code for those.
By the way : The DOS version I'm currently testing it on is v5.0.
Regards,
Rudy Wieser
Rod Pemberton
"R.Wieser" <add...@not.available> wrote in message
> Rod Pemberton <dont...@bitbucket.cmm> schreef in berichtnieuws
> rnhj93-...@news.infowest.com...
> By the way : The DOS version I'm currently testing it on is v5.0.
What happens with other dos versions? Say, perhaps, 6.22?
If you've got the time, how does the interrupt flow between the two PC's?
Does it go something like this?
PC#1 -> int 21, ax=6c00h -> int 2f, ax=112eh -> data over network cable ->
PC#2 -> int 21, ax=6c00h
Rod Pemberton
R.Wieser
Hello Rod,
> > By the way : The DOS version I'm currently testing it on is v5.0.
>
> What happens with other dos versions? Say, perhaps, 6.22?
I'm not quite sure. Some of the data in the SDA that I need is on
different places depending on the DOS-version, but I have to check & see
which DOS-version uses which INTs (DOS v3.x probably won't use DOS v4.0(+)
calls :-) )
> If you've got the time, how does the interrupt flow between the two PC's?
> Does it go something like this?
>
> PC#1 -> int 21, ax=6c00h -> int 2f, ax=112eh -> data over
> network cable -> PC#2 -> int 21, ax=6c00h
Not quite. Only one machine is supposed to be DOS. The other side (the
"server") is supposed to be a Windows-machine.
But even the DOS side does not call INT 21h. Low-level requests like DIR,
COPY (from or to the remote machine), etc all seem to go directly to INT
2Fh, AH=11h.
Regards,
Rudy Wieser
P.s.
Today I got a chance to test my programs (DOS client and Window server) on a
noisy (well-used) LAN. Apart from one mistake in not clearing received (not
for me) ARP-requests both seemed to work well. Slow, but as far as I can
see reliable. :-)
Rod Pemberton
"R.Wieser" <add...@not.available> wrote in message
> Rod Pemberton <dont...@bitbucket.cmm> schreef in berichtnieuws
> d8sk93-...@news.infowest.com...
>
RP here again,
CPHANTOM says it has the following working:
Installation Check - Subfunction 00h
RmDir - Subfunction 01h
MkDir - Subfunction 03h
ChDir - Subfunction 05h
CloseFile - Subfunction 06h
Read - Subfunction 08h (Returns garbage...)
Write - Subfunction 09h (Increments file size...)
GetDiskSpace - Subfunction 0Ch (Returns constant values...)
SetFileAttrib - Subfunction 0Eh
GetFileAttrib - Subfunction 0Fh
RenameFile - Subfunction 11h
DeleteFile - Subfunction 13h
OpenFile - Subfunction 16h
CreateFile - Subfunction 17h
FindFirst - Subfunction 1Bh
FindNext - Subfunction 1Ch
SeekFromEnd - Subfunction 21h
SpecialOpen - Subfunction 2Eh
Rod Pemberton
"R.Wieser" <add...@not.available> wrote in message
> Rod Pemberton <dont...@bitbucket.cmm> schreef in berichtnieuws
> d8sk93-...@news.infowest.com...
>
That other redirector program, CPHANTOM, that I mentioned in another thread,
has the code below for 2Eh. I don't know whether it is client or server or
useful.
Rod Pemberton
/* Multi-Function Open - Subfunction 2Eh
----------------------------------------
* Called in DOS 4.XX+ only.
*/
static int doSpecialOpen( void )
{
Uint16 ParentID, Result;
NodeParms *nodePtr;
Result = 0;
/* Search For Matching Files
---------------------------- */
ParentID = VCATDistillDir( 2, FN1Dir );
nodePtr = VCATFindFirst( ParentID, FN1Template );
if( nodePtr )
{
/* Can Only Open Files!
----------------------- */
if( nodePtr->fattr & ( _A_VOLID | _A_SUBDIR ) )
{
fsFailCall( EACCES ); // Access Denied
return( 0 ); // Call Processed
}
/* Action If File Exists
------------------------ */
if( ( SDA_SPOP_ACT & 0x0F ) == 0 )
{
fsFailCall( EACCES ); // Access Denied
return( 0 ); // Call Processed
}
/* For Open Or Truncate, Check Access Mode
------------------------------------------ */
if( ( SDA_SPOP_ACT & 0x03 ) != 0 )
{
/* Check Access Mode
-------------------- */
switch( SDA_SPOP_MODE & 0x03 )
{
case 0: // Read-Only
break;
case 1: // Write-Only
case 2: // Read/Write
if( nodePtr->fattr & _A_RDONLY )
{
fsFailCall( EACCES ); // Access Denied
return( 0 ); // Call Processed
}
break;
default:
break;
}
}
if( ( SDA_SPOP_ACT & 0x01 ) != 0 )
{
/* Open The File
---------------- */
Result |= 0x01; // File Opened
}
else if( ( SDA_SPOP_ACT & 0x02 ) != 0 )
{
/* Can't Truncate An Open File
------------------------------ */
/* Open The File
---------------- */
/* Truncate The File
-------------------- */
nodePtr->FlLgLen = 0; // That's All For CPhantom...
Result |= 0x03; // File Replaced
}
else
{
/* Invalid Action - Wasn't Fail, Open, Or Truncate
-------------------------------------------------- */
nodePtr = (NodeParms * )NULL;
}
}
else
{
/* Action If File Does Not Exist
-------------------------------- */
if( ( SDA_SPOP_ACT & 0xF0 ) == 0 )
{
fsFailCall( EACCES ); // Access Denied
return( 0 ); // Call Processed
}
else if( ( SDA_SPOP_ACT & 0x10 ) != 0 )
{
/* Find Empty Directory Entry
----------------------------- */
nodePtr = VCATGetFreeNode();
if( !nodePtr )
{
fsFailCall( 0x82 ); // Ran Out Of Directory Entries
return( 0 ); // Call Processed
}
/* Initialize The Empty Directory Entry
--------------------------------------- */
nodePtr->ParentID = ParentID;
memcpy( nodePtr->fname, FN1Template, 11 );
nodePtr->fattr = SDA_SPOP_ATTR;
/* Assign Current Date/Time
--------------------------- */
nodePtr->date_lstupd = fsDate();
nodePtr->time_lstupd = fsTime();
nodePtr->FlLgLen = 0;
Result |= 0x02; // File Created
}
else
{
/* Invalid Action Wasn't Fail Or Create
--------------------------------------- */
nodePtr = (NodeParms * )NULL;
}
}
if( nodePtr )
{
/* Initialize The Supplied SFT Entry
------------------------------------ */
memcpy( sftPtr->filename, nodePtr->fname, 11 );
sftPtr->open_mode = SDA_SPOP_MODE & 0x7F;
sftPtr->attr_byte = nodePtr->fattr;
sftPtr->f_size = nodePtr->FlLgLen;
sftPtr->f_pos = 0L;
sftPtr->dev_info = 0x8040 | drive_no;
sftPtr->dir_entryno = nodePtr->FlDrID;
sftPtr->devdrv_ptr = NULL;
fsSetSFTOwner( sftPtr );
rsPtr->x.dx = Result;
}
if( !nodePtr )
{
fsFailCall( ENOPATH ); // Path Not Found
}
return( 0 ); // Call Processed
}
R.Wieser
Hello Rod,
> That other redirector program, CPHANTOM, that I mentioned
> in another thread, has the code below for 2Eh. I don't know
> whether it is client or server or useful.
I've got that code (downloaded it quite some time ago), and just took
another look at it. When I first looked at it it was just to overwelming,
and I just did not know where to start.
Currently I have a better grasp of what IFS does, and I think it could show
me a trick or two (although it does not seem to adress the ExtendedOpen
arguments-bug in DOS v5.0+).
Thanks for the pointer/reminder (again :-) ).
Regards,
Rudy Wieser