Re: [Freedos-kernel] FreeDOS and redirectors

[Eduardo Casino]

2015-11-17 6:35 GMT+01:00 H. Peter Anvin :
> I wanted to ask: to what degree does FreeDOS implement the redirector
> interface?  Are there any known incompatibilities?

I didn't find any while implementing my own redirector.

> The reason I am asking is that I started a project that I was never able
> to find time finish (and don't expect to have any more for the
> forseeable future) to write a 9pfs redirector for DOS, which would let
> DOS access a filesystem (as opposed to a disk image) using Qemu.

...and, therefore, using KVM. Great!  :)

> If there is interest, the code so far is at:
>
> http://git.zytor.com/dos/virtio9p.git/
>
> It contains a lot of infrastructure work done (tested under MS-DOS 6.22)
> but not much of the actual file operations.
>
> This also requires that any protected mode memory manager (EMM386 etc)
> implements the DOS VDS (Virtual DMA Service, INT 4Bh AH=81h) API.

I will look into that, thank you.

Eduardo.

--
___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel

[Freedos-kernel] Patch: UNSTABLE: Add int 2F 122B and 122D support

[Eduardo Casino]

Hello All,

This patch adds support for int 2F122B (Internal IOCTL) and int 2F122D
(Internal Get Extended Error) to kernel.

Those are necessary for the upcoming new version of NLSFUNC to work with
DISPLAY 1.0.

Regards,
Eduardo.

diff -uNrp /home/eduardo/fdos/kernel/cvs/unstable/kernel/kernel/inthndlr.c 
kernel/kernel/inthndlr.c
--- /home/eduardo/fdos/kernel/cvs/unstable/kernel/kernel/inthndlr.c 
2005-12-08 13:51:26.0 +0100
+++ kernel/kernel/inthndlr.c2005-12-08 14:12:50.340721000 +0100
@@ -2233,12 +2233,40 @@ VOID ASMCFUNC int2F_12_handler(struct in
   r.FLAGS = ~FLG_CARRY;
   break;
 
+case 0x2b: /* Device I/O Control */
+  if (r.BP  0x4400 || r.BP  0x44ff)
+goto error_invalid;
+  {
+lregs lr;
+lr.AX = r.BP;
+lr.BX = r.BX;
+lr.CX = r.CX;
+lr.DX = r.DX;
+lr.DI = r.DI;
+lr.SI = r.SI;
+lr.DS = r.DS;
+rc = DosDevIOctl(lr);  /* can set critical error code! */
+  }
+
+  if (rc  SUCCESS)
+  {
+r.AX = -rc;
+if (rc != DE_DEVICE  rc != DE_ACCESS)
+  CritErrCode = r.AX;
+goto error_carry;
+  }
+  break;
+
 case 0x2c: /* added by James Tabor For Zip Drives
Return Null Device Pointer  */
   /* by UDOS+RBIL: get header of SECOND device driver in device chain, 
  omitting the NUL device TE */
   r.BX = FP_SEG(nul_dev.dh_next);
   r.AX = FP_OFF(nul_dev.dh_next);
+  break;
+
+case 0x2d: /* Get Extended Error Code */
+  r.AX = CritErrCode;
   /* fall through only to re-use break */
 case 0x2e: /* GET or SET error table addresse - ignored
called by MS debug with  DS != DOSDS, printf
@@ -2285,6 +2313,7 @@ error_exit:
   r.AX = -rc;
   if (CritErrCode == SUCCESS)
 CritErrCode = r.AX;  /* Maybe set */
+error_carry:
   r.FLAGS |= FLG_CARRY;
 }
 




---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click
___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel

Re: [Freedos-kernel] Reading new COUNTRY.SYS records

[Eduardo Casino]

El lun, 13-09-2004 a las 12:36, Luchezar Georgiev escribió: 
 Eduardo, couldn't we divide the work between ourselves? If you do the 
 changes in nls_hc.asm for the third option you offered (make enough room), 
 I will add the necessary code in config.c ;-)

Hi Lucho,

I don't mind adding the changes to nls_hc.asm, but I'm not sure that I
like that option.

In a private mail, Eric suggested a fourth option: Check if there is
enough room for loading the package and, if not, allocate extra memory
only for the additional tables.

This will keep the kernel size unchanged and optimze the memory useage,
as only a percentage of NLS packages are bigger than the default.

I've been thinking about how to implement this, and I've come up with
this:

We could insert a null pointer for subfunction 0 just before subfunction
1 (CTYINFO) into nls_hc.asm, which will be ignored by NLS functions as
subfunction 0 does not exist (example patch below). This will add just 5
bytes to the tables and can be used as a placeholder for subfunction 3
(LCASE). This maintains all the pointers into predictable indexes and
prevents moving the CTYINFO table when loading a package with LCASE.

When loading a package from COUNTRY.SYS, we should do something like the
following pseudocode before actually reading the data:

extra_memory = 0;

if (LCASE_is_present)
extra_memory += 258; /* sizeof(WORD) + actual length */

if (UCASE_offset != FUCASE_offset)
extra_memory += 130;

if (DBCS_length != 0)
extra_memory += 2 + DBCS_length; /* sizeof(WORD) + actual_length */ 

allocate(extra_memory);

And then, read the info overwriting the harcoded tables for UCASE,
FCHAR, CTYINFO, YESNO and COLLATE and into the allocated memory for
LCASE, FUCASE (if different than UCASE) and DBCS (if non-empty.)

Comments?

Eduardo.


--- unstable/kernel/kernel/nls_hc.asm 2002-12-09 01:17:14.0
+0100
+++ unstable.new/kernel/kernel/nls_hc.asm 2004-09-13 16:29:08.831007552
+0200
@@ -12,7 +12,7 @@
GLOBAL _nlsPackageHardcoded
_nlsPackageHardcoded:
DB  000h, 000h, 000h, 000h, 001h, 000h, 0b5h, 001h
- DB  00fh, 000h, 059h, 000h, 04eh, 000h, 006h, 000h
+ DB  00fh, 000h, 059h, 000h, 04eh, 000h, 007h, 000h
DB  002h
DW ?table2, SEG ?table2
DB  004h
@@ -23,6 +23,8 @@
DW ?table6, SEG ?table6
DB  007h
DW ?table7, SEG ?table7
+ DB  000h
+ DW  000h  , 000h ; Placeholder for table3 (LCASE)
GLOBAL _nlsCountryInfoHardcoded
_nlsCountryInfoHardcoded:
DB  001h




---
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php
___
Freedos-kernel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-kernel

Re: [Freedos-kernel] Reading new COUNTRY.SYS records

[Eduardo Casino]

El lun, 13-09-2004 a las 19:19, Luchezar Georgiev escribió:
  In a private mail, Eric suggested a fourth option: Check if there is 
  enough room for loading the package and, if not, allocate extra memory 
  only for the additional tables.
 
  This will keep the kernel size unchanged and optimze the memory useage, 
  as only a percentage of NLS packages are bigger than the default.
 
 The problem is that the already statically allocated memory for hard-coded 
 tables will be lost.

Not really. In the worst case, only the 4 bytes for the empty DBCS table
will be unused. The idea is to overwrite the hardcoded tables for
CTYINFO, UCASE, FCHAR, and COLLATE and allocate new memory (if needed)
for FUCASE, LCASE and DBCS _only_. 


  I've been thinking about how to implement this, and I've come up with 
  this:
 
  We could insert a null pointer for subfunction 0 just before subfunction 
  1 (CTYINFO) into nls_hc.asm, which will be ignored by NLS functions as 
  subfunction 0 does not exist (example patch below). This will add just 5 
  bytes to the tables and can be used as a placeholder for subfunction 3 
  (LCASE). This maintains all the pointers into predictable indexes and 
  prevents moving the CTYINFO table when loading a package with LCASE.
 
  When loading a package from COUNTRY.SYS, we should do something like the 
  following pseudocode before actually reading the data:
 
  extra_memory = 0;
 
  if (LCASE_is_present)
  extra_memory += 258; /* sizeof(WORD) + actual length */
 
  if (UCASE_offset != FUCASE_offset)
  extra_memory += 130;
 
  if (DBCS_length != 0)
  extra_memory += 2 + DBCS_length; /* sizeof(WORD) + actual_length */
 
  allocate(extra_memory);
 
  And then, read the info overwriting the harcoded tables for UCASE, 
  FCHAR, CTYINFO, YESNO and COLLATE and into the allocated memory for 
  LCASE, FUCASE (if different than UCASE) and DBCS (if non-empty.)
 
 But we will have a common memory for all the information and could not 
 distinguish between the beginnings of the different structures. It's 
 better to allocate memory separately for each one.

I don't see the point. You have the array of nlsPointer structures,
which tells you where the tables are for each subfunction. If you have a
look at nls_hc.asm, maybe it will be clearer. 

 I still think that half a kilobyte isn't a big price to pay, PROVIDED THAT 
 SOMEONE WILL REALLY USE THE DOUBLE-BYTE TABLES. As far as I know, there 
 are complete Chinese, Korean and Japanese packages that install their own 
 font, NLS and keyboard support, and most people will use them and not our 
 inferior but much more difficult to set up COUNTRY + NLSFUNC + DISPLAY 
 + KEYBOARD + whatever :-/
 
 If nobody will use them, then your option (1) is the one to implement.

Not only DBCS. Also LCASE (for Russian) or FUCASE, for other languages.
But yes, it is only a percentage.

 Chinese, Japanese and Korean friends, please express your opinion now.
 
 Last not least, we don't have these tables yet, and may not have them.
 
 Regards,
 Lucho

Regards,
Eduardo.



---
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php
___
Freedos-kernel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-kernel

Re: [Freedos-kernel] Patch: COUNTRY.ASM

[Eduardo Casino]

Hello,

I uploaded the wrong patch to my page. I have updated it now, so please
download it again from the same location:

http://perso.wanadoo.es/samelborp/country.zip

Sorry for the inconvenience.

Eduardo.



---
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM. 
Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php
___
Freedos-kernel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-kernel

[Freedos-kernel] #pragma in UNSTABLE breaks compilation with OpenWatcom 1.2

[Eduardo Casino]

Hi!

This is the offending line:

portab.h, line 127:

#pragma aux default parm [ax dx cx] modify [ax dx es fs] /* min.unpacked
size */

And this is the error message:

c:\wc\binw\wcc @wc.cfg -Ic:\wc\h -DWITHFAT32 dsk.c
DOS/4GW Protected Mode Run-time  Version 1.97
Copyright (c) Rational Systems, Inc. 1990-1994
dsk.c(92): Error! E1122: Illegal register modified by 'getddt' #pragma
dsk.c(101): Error! E1122: Illegal register modified by 'tdelay' #pragma
dsk.c(173): Error! E1122: Illegal register modified by '.F' #pragma
dsk.c(173): Error! E1122: Illegal register modified by 'getddt' #pragma
dsk.c(182): Error! E1122: Illegal register modified by 'play_dj' #pragma
dsk.c(198): Error! E1147: Too many errors: compilation aborted
Error(E42): Last command making (dsk.obj) returned a bad status

Eduardo.



---
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM. 
Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php
___
Freedos-kernel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-kernel

Re: [Freedos-kernel] Announce: COUNTRY.SYS

[Eduardo Casino]

Lucho wrote:

 We strive for MS-DOS compatibility, and MS-DOS, PC-DOS, PTS-DOS, OS/2, 
 Windows 9x and Windows NT all use the same format that is so well 
 described in the RBIL tables 2619-2622. So I chose that.

IMHO, the COUNTRY.SYS format does not affect compatibility, as the
information is accessed through DOS interrupts. DR-DOS, for instance,
uses a different one.

I won't hide that I prefer Steffen's format, as I've already implemented
NLSFUNC using that but, if we finally go for the MS format, we should
consider to expand it to include a Yes/No table (for int 21.65.23),
which is a nice addition in Steffen's version. It is pretty
straightforward, but it will invalidate the use of COUNTRY.SYS files
from those OSes in FreeDOS (apart from legal and/or ethical issues).

Regards,
Eduardo.

 



---
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink  Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
___
Freedos-kernel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-kernel

Re: [Freedos-kernel] Strange bug in kernel 2035

[Eduardo Casino]

Hello again,

 2. nlsfunc would have to copy anything in between ss:sp and ss:920
(_disk_api_tos, that's the top of the stack used here in any DOS = 
 4.0) to a temp area (max 384 bytes), set sp to 920, and with that call 
 DOS. Then after the call adjust the stack pointer, then swap it back,
 then return.
 
 2. is probably easiest unless we also like to experiment with 3rd party 
 NSLFUNCs. There may be funny problems I didn't think of but can't 
 think of any though.

There are. If I understand it correctly, when calling DOS with ss:920,
the flags and return address are trashed because DOS sets ss:920 on
entry, again. The one that has worked for me is:

- Switch to a local stack
- copy anything in between the original ss:sp and ss:920 to a temp area
- call DOS ints
- restore from temp area
- switch to original stack
- return

Does anybody see any additional problem with this?

Eduardo.



---
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=4721alloc_id=10040op=click
___
Freedos-kernel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-kernel

Re: [Freedos-kernel] Strange bug in kernel 2035

[Eduardo Casino]

El lun, 26-07-2004 a las 14:09, Bart Oldeman escribió:

 No. The whole point of calling int2f/ax=12xx is that this stack setup is
 bypassed.
 
 i.e. *without* any swapping in NLSFUNC you'd have
 int21/ah=38 = DOS switches to internal stack =
 NLSFUNC (still uses DOS stack) = int2f/ax=12xx = back in DOS at a lower
 place on the same stack.
 
 Now it's just very easy to use too much stack in this setup and that's the
 whole problem.
 
  - Switch to a local stack
  - copy anything in between the original ss:sp and ss:920 to a temp area
  - call DOS ints
  - restore from temp area
  - switch to original stack
  - return
 
  Does anybody see any additional problem with this?
 
 you should not use a local stack when you call int2f/ax=12xx.
 As RBIL states: SS = DOS DS (must be using a DOS internal stack)

I understood all of this the wrong way. I thought that you were saying
to call _int21_, that's the reason for the local stack.

  Excuse me if I'm a bit thick in the head. Do you mean that it makes
no
  sense to implement the int 2f122[6-9b] functions in FreeDOS and it is
  better to do what you suggested in your previous post?
 
 No, it makes sense to implement them, but you're understanding of RBIL
 apparently was wrong -- it isn't talking about switching stacks but about
 pointing to a different stack frame.

So, now that I know how to solve the stack problem, is my implementation
of int2f/ax122[6-9] correct?
(http://sourceforge.net/mailarchive/message.php?msg_id=8802703)

Eduardo.



---
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_idG21alloc_id040op=click
___
Freedos-kernel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-kernel

Re: [Freedos-kernel] PATCH: nls.c

[Eduardo Casino]

Hello Steffen,

 Sorry it took so long.

No problem, I suppose that you are busy.

(For the list: This is a reply to a message I sent to Steffen off the
list and that I've attached to the end of this one)

 Honestly, I would like to:
 
 a) either get my whole distribution off the kernel or

A bit too drastical, I would say...

 b) get in touch with you about the internals and the design decissions.

I've not asked you about this before because I wanted to learn more
about the current implementation before bothering you with silly
questions, but I'll be more than happy to start the discussion.

Right now, I've made a first implementation of MUX-14-02 and MUX-14-04
(Get Extended Country Info and Get Country Info) which I believe that
are functionally correct, although there is room for optimizations.
These functions (the whole NLSFUNC, in fact) relay on a working
implementation of MUX-12-26 to MUX-12-29 (Internal Open, Close, Seek and
Read). I have implemented them to test NLSFUNC, but Tom Ehlert warned
that they are using, and probably overrunning, the kernel stack, so they
are not valid for real life. Unfortunately, my poor knowledge of the
kernel internals does not allow me to fix it myself.

If I've understood your NLS implementation correctly, MUX-14-01 and
MUX-14-03 (Change Code Page  Set Code Page) should both read the info
for the country-cp pair from COUNTRY.SYS (in fact, MS-DOS MUX-14-03
ignores the cp even if cp != -1 and loads the info for the first country
code match), allocate enough memory, populate the nlsPackage structure
(including all the tables that are relevant), add it to the chain in the
nlsInfoBlock, and point actPkg to it. Then, MUX-14-01 will inform the
relevant drivers issuing the necessary ioctls. I understand that
sysCodePage should not be updated (?)

The internal ioctl (MUX-12-2B) is not yet implemented, but it seems easy
once (if) the stack problem is solved. I do not know yet how to allocate
memory from within these functions, as they are called by the kernel
itself and so it is not possible to use the int21 functions.

MUX-14-00 is trivial and implemented.

For the rest of MUX-14 functions, I've not yet looked at them, but they
seem to be easy to implement. nlsYesNo() will require a COUNTRY.SYS
extension, though. Anyway, what is the reason for pushing nlsYesNo(),
nlsUpMem() and nlsUpFMem() through the mux?

Regards,
Eduardo.

---
Eduardo Casino wrote:

Hi Steffen,

There's still a problem with your suggestion (and with present
searchPackage() ). As default values are resolved _inside_ the
function, they are not propagated correctly to the mux functions if
searchPackage() returns NULL. A simple solution could be to pass
cp and cntry by reference to searchPackage().

What do you think?

Eduardo.




---
This SF.Net email sponsored by Black Hat Briefings  Training.
Attend Black Hat Briefings  Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com
___
Freedos-kernel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-kernel

Re: [Freedos-kernel] PATCH: nls.c

[Eduardo Casino]

El vie, 25-06-2004 a las 08:42, Steffen Kaiser escribió:
 I would actually suggest the following function, as searchPackage is
to 
 resolve the default values as well; otherwise your patch breaks the 
 possibility of non-direct (MUX-only) country data, which in turn
breaks 
 the whole current NLS design, which would make it better to replace
all 
 the code.

Thanks. This looks much better, indeed. I assume that you are fixing it
yourself, aren't you? Or do you want me to generate the modified patch?

Eduardo.




---
This SF.Net email sponsored by Black Hat Briefings  Training.
Attend Black Hat Briefings  Training, Las Vegas July 24-29 -
digital self defense, top technical experts, no vendor pitches,
unmatched networking opportunities. Visit www.blackhat.com
___
Freedos-kernel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-kernel

Re: [Freedos-kernel] PATCH: inthndlr.c

[Eduardo Casino]

Hi Tom,

 a)
 why do you need int2f/12 in the first first place ?
 are you really executing this from inside KERNEL ?
 do you really need to use internal functions ?

Yes. NLSFUNC implements kernel extensions to access NLS data from an
external file (namely COUNTRY.SYS) and these extensions are called from
inside the kernel (int 21/65, int 21/38)

 if YES, you will probably greatly overrun the kernels 384 byte stack,
 which might become a problem.

OK. How do I setup a different stack for these functions? 

 b) lseek(0x1) will fail due to fall from locng_check into
 shortcheck.

Then we have a real problem, because this was copied from the int 21/42
implementation.

Eduardo.



---
This SF.Net email sponsored by Black Hat Briefings  Training.
Attend Black Hat Briefings  Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com
___
Freedos-kernel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-kernel

[Freedos-kernel] PATCH: nls.c

[Eduardo Casino]

Hi,

Trivial patch. Pass correct values for codepage and country from DOS-38
and DOS-65-XX functions to MUX-14 functions.

Eduardo.

diff -uNrp ke2035.orig/kernel/nls.c ke2035/kernel/nls.c
--- ke2035.orig/kernel/nls.c2004-06-24 22:41:18.0 +0200
+++ ke2035/kernel/nls.c 2004-06-24 22:15:52.0 +0200
@@ -520,8 +520,8 @@ COUNT DosGetData(int subfct, UWORD cp, U
direct-access flag is disabled, the request must
be passed through MUX */
 return (subfct == NLS_DOS_38)
-? mux38(nls-cp, nls-cntry, bufsize, buf)
-: mux65(subfct, nls-cp, nls-cntry, bufsize, buf);
+? mux38(cp, cntry, bufsize, buf)
+: mux65(subfct, cp, cntry, bufsize, buf);
   }
 
   /* Direct access to the data */




---
This SF.Net email sponsored by Black Hat Briefings  Training.
Attend Black Hat Briefings  Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com
___
Freedos-kernel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-kernel

[Freedos-kernel] PATCH: inthndlr.c

[Eduardo Casino]

Hi!

I'm implementing NLSFUNC for FreeDOS and I've found that many (most) of
the needed MUX functions are missing.

This patch implements functions 2F1226h to 2F1229h. This, together with
my previous nls.c patch, allowed me to make a first working
implementation of NLSFUNC's int 2F1404h, but the patch looks so simple
that I must have done something wrong :)  so, kernel guys, please, have
a look at it. It is mainly cut'n'paste from int21_service()

Eduardo.


diff -uNrp ke2035.orig/kernel/inthndlr.c ke2035/kernel/inthndlr.c
--- ke2035.orig/kernel/inthndlr.c   2004-06-24 22:41:20.0 +0200
+++ ke2035/kernel/inthndlr.c2004-06-24 22:41:09.0 +0200
@@ -1656,6 +1656,9 @@ struct int2f12regs {
  */
 VOID ASMCFUNC int2F_12_handler(struct int2f12regs r)
 {
+  COUNT rc;
+  long lrc;
+
   if (r.AH == 0x4a)
   {
 size_t size = 0, offs = 0x;
@@ -1869,6 +1875,42 @@ VOID ASMCFUNC int2F_12_handler(struct in
   r.CX = fstrlen(MK_FP(r.DS, r.SI)) + 1;
   break;
 
+case 0x26: /* open file */
+  r.FLAGS = ~FLG_CARRY;
+  CritErrCode = SUCCESS;
+  lrc = DosOpen(MK_FP(r.DS, r.DX), O_LEGACY | O_OPEN | r.CL, 0);
+  goto long_check;
+
+case 0x27: /* close file */
+  r.FLAGS = ~FLG_CARRY;
+  CritErrCode = SUCCESS;
+  rc = DosClose(r.BX);
+  goto short_check;
+
+case 0x28: /* move file pointer */
+  r.FLAGS = ~FLG_CARRY;
+  CritErrCode = SUCCESS;
+  r.BP = 0x00ff;
+  if (r.BP  2)
+goto error_invalid;
+  lrc = DosSeek(r.BX, (LONG)ULONG) (r.CX))  16) | r.DX),
r.BP);
+  if (lrc == -1)
+  {
+lrc = DE_INVLDHNDL;
+  }
+  else
+  {
+r.DX = (UWORD)(lrc  16);
+lrc = (UWORD) lrc;
+  }
+  goto long_check;
+
+case 0x29: /* read from file */
+  r.FLAGS = ~FLG_CARRY;
+  CritErrCode = SUCCESS;
+  lrc = DosRead(r.BX, r.CX, MK_FP(r.DS, r.DX));
+  goto long_check;
+
 case 0x2a: /* Set FastOpen but does nothing. */
 
   r.FLAGS = ~FLG_CARRY;
@@ -1897,6 +1939,26 @@ VOID ASMCFUNC int2F_12_handler(struct in
 r.FLAGS |= FLG_CARRY;
   }
   }
+  goto real_exit;
+long_check:
+  if (lrc = SUCCESS)
+  {
+r.AX = (UWORD)lrc;
+goto real_exit;
+  }
+  rc = (int)lrc;
+short_check:
+  if (rc  SUCCESS)
+goto error_exit;
+  goto real_exit;
+error_invalid:
+  rc = DE_INVLDFUNC;
+error_exit:
+  r.AX = -rc;
+  if (CritErrCode == SUCCESS)
+CritErrCode = r.AX;  /* Maybe set */
+  r.FLAGS |= FLG_CARRY;
+real_exit:;
 }
 
 /*




---
This SF.Net email sponsored by Black Hat Briefings  Training.
Attend Black Hat Briefings  Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com
___
Freedos-kernel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-kernel