##############################################################################
##                             WDOSX 0.93                                   ##
##############################################################################

0.   INTRODUCTION

1.   GETTING STARTED
1.1. GETIING STARTED WITH TASM
1.2. GETIING STARTED WITH NASM
1.3. GETTING STARTED WITH BORLAND DELPHI 2
1.4. GETTING STARTED WITH BORLAND C/C++

2.   MORE TECH STUFF
2.1. INTERRUPTS AND EXCEPTIONS
2.2. MEMORY LAYOUT

3.   THE WDOSX API
3.1. DPMI 0.9 FUNCTIONS NOT SUPPORTED
3.2. DPMI 0.9 FUNCTIONS SUPPORTED
3.3. EXTENDED DOS API
3.4. PROPRIETARY WDOSX FUNCTIONS


0. INTRODUCTION
==============================================================================

Finally, here it is. A new version of WDOSX. I wish I had more time to improve
on the documentation,  examples etc.  The main reason I release this right now
is that there have been so many bugs fixed since 0.92 was released that I find
it unacceptable for  you to stick with 0.92.  The same is true for WUSTUB, the
Delphi 2 variant of WDOSX.  Yeah, and last but not least, we have some sort of
a debugger now.

So be patient, there WILL be a WDOSX 0.94 and so on...

WDOSX is a free DOS extender  (yet another one)

WDOSX 0.93 fully replaces WDOSX/N, WDOSX 0.92, and WUSTUB 0.2. from the former
archives:

- wdosxn02.zip
- wdosx092.zip
- wustub02.zip

WDOSX supports  RAW/XMS/VCPI/DPMI  memory allocation.  It has built in support
for  almost  all  of the  DPMI 0.9 API functions.  It also  provides  extended
versions of the most frequently used DOS INT 21H functions.

WDOSX now supports four different executable file formats:

- 32 bit DOS ("MZ") execcutables

- 32 bit flat form binary files ( the default output format of NASM )

- PE- executables not using the Windows API, preferrably written in ASM

- PE- executables using a certain subset of the Win32 API functions,
  preferrably written in some HLL ( WDOSX has been tested with Borland
  Delphi 2 and Borland C/C++, it may/may not work with other compilers )

All of the above are  supposed to be prepended to your executable.  Usually, a
"copy /b" did the job in past releases. The principles have not changed though
but now there is a program called  "stubit.exe"  that will do the job a little
more  comfortable.  It contains all necessary  modules of WDOSX and will auto-
matically ( hopefully ) select the right one to prepend, depending on the type
of your executable. "stubit.exe" will also replace any existing WDOSX stub, so
it's easy to "re- stub" files created with older versions of WDOSX / WUSTUB.

If you already  worked with  WDOSX  and you don't like the new method for some
reason, type  "stubit -extract"  and it will  create  the files "wdosx.dx" and
"pestub.exe" as known from past releases of  WDOSX / WUSTUB.  Users of WDOSX/N
may want to rename  "wdosx.dx" into "wdosx.nas" to get everything as it's been
before ;-)

No special linking, parameter setting etc. In short: No user serviceable parts
inside! This makes WDOSX very easy to use, I think.

WDOSX has been written by:

      Michael Tippach
      Stockartstrasse 27
      04277 Leipzig (Germany)

      Phone/Fax:  +49 341 3028848
                  +49 161 3322758

      email    :  tippachm@dialin.deh.de            (preferred)
                  tippach@metronet.de               (backup)
                  heiko.friedel@phil.tu-chemnitz.de (last ressort)
                  wuschel@geocities.com             (they say it works...)


WDOSX is freeware.  Then  again, if you  really,  really feel like  sending me
money, beer or so, I surely won't complain ;-)

See the file "legal.txt" for the stuff that makes lawyers happy.

See the file "whatsnew.txt" if you are already familar with WDOSX.

Anyone  willing  to correct the  misspellings  and grammar errors in the WDOSX
doc's and send some clean English versions back to me? Millions of WDOSX users
all over the known universe, including me, would very much appreciate this!
</kidding>


################################# CREDITS ####################################


           James Budiono, Chet Simpson, Niklas Martinsson, Johan Prins,
           Eriks Aleksans, Mark Junker, Marko Guth, ...

           - Thank you for reporting bugs and so on!
             ( You all probably know what "so on" means )

           Simon Tahtham / Julian Hall

           - The authors of NASM. With their kind permission I use their
             instruction decode routine in the debugger. Thanks for NASM
             anyway!

           Ralf Brown
           ( Well, we all know... )

           All the folks on comp.lang.asm.x86. This is a wonderful group,
           except when they're discussing:

           - ASM vs. C
           - ASM vs. C++
           - ASM vs. D
           - ASM vs. D++
           - ASM vs. E
           - Ape goes Int*l- shit ( or was it backwards... )
           - [...]
           - Scott Nudd's underwear
           - TERSE(tm)- clones or CLONES(tm) of TERSE(tm)- clones...

           I'm sure I forgot someone. Murphy's law says I forgot the
           one who helped me the most... Well, you know who you are,
           don't you?

           Generally: Thanks to all people giving away something
                      useful for free !

##############################################################################




1. GETTING STARTED
==============================================================================

1.1. GETTING STARTED WITH TASM
------------------------------------------------------------------------------

- Note that with MASM it is basically the same. You should be able to figure -
- it out yourself without significant difficulties.                          -

There  are two ways  to go with  TASM.  You could create a "32-bit Tiny Model"
executable in DOS "MZ" format or you could decide that using the ".model flat"
directive and linking to a PE executable would be the better choice.

However, WDOSX supports both formats.

To get a 32 bit DOS "MZ" executable, you'd have to write your code as follows:

------------------------ 8< ---------------------------
.386p
code    segment use32
assume  cs:code,ds:code,ss:code

hwstring db 'HELLO WORLD!',0dh,0ah,'$'

start:
        ; enable virtual interrupts

	mov    ax,0901h
        int    31h

        mov    edx,offset hwstring
        mov    ah,9
        int    21h

        ; terminate

        mov    ax,4c00h
        int    21h

code    ends
end     start
------------------------ 8< ---------------------------

Make sure there's only one segment, don't use ".model flat"!

TASM it:             "TASM     mycode.asm"
TLINK it:            "TLINK /3 mycode"

Now you've got a "mycode.exe".  Don't run it as it is unless you like the BIOS
memory counter's tick sound!

At this point WDOSX comes into play. Type in:      "stubit mycode.exe"

"mycode.exe" will be your DOS extended program then. You should be able to run
it without watching your computer reboot since  WDOSX takes care of the 32 bit
nature of your program.

WDOSX will start your  "32-bit MZ" executable program with the following entry
conditions:

cs:                     guess what!
ds,ss:                  alias(cs)
es:                     selector(PSP)
esp:                    size of flatmode ovelay + 1k = initial segment size
                        dword aligned
anything else:          undefined
virtual interrupts:     disabled

"inital segment size" is taken from the .exe header (offset 02 and 04) of your
program. Basically, it's the overall size of your program code and initialized
data. You may want to expand the initial segment size later on.

See the description of INT 21/FFFF below for that matter!

Alternatively you could write your executable in true flat model e.g.

;---------------- 8< ---------------------------
.386
.model flat
.code

start:

               ; I will explain this below...

               mov    EndOfBlock,esp
               mov    argc,esi
               mov    argv,edi
               mov    env,ebp
               mov    PspSel,es

               ; print the hello world thing

               lea    edx,HwString
               mov    ah,9
               int    21h

               ; terminate

               mov    eax,4c00h
               int    21h

.data

HwString       db 'Hello, world',0dh,0ah,'$'

.data?

argc           dd ?
argv           dd ?
env            dd ?
PspSel         dd ?
EndOfBlock     dd ?

end start
;---------------- 8< ---------------------------

TASM it: "TASM example.asm"  ( or "TASM32 example.asm" for that matter )
LINK it  "TLINK32 example"
STUB it  "stubit example.exe"

STUBIT.EXE will include extra code taking advantage of the "PE nature" of your
file. For a non- trivial example on this, look at the debugger sourcecode!

!!! WARNING: DON'T USE DYNAMIC LINKAGE WITH THESE KINDS OF PE EXECUTABLES !!!!

The reason for this is that stubit.exe  automatically  will select a different
stub if it detects that your program uses the Windows API.   The Win32 variant
of WDOSX will load your program though,  but with  different entry conditions.
( as a Win32 program expects them to be )

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

So what do argc, argv etc. mean?  Well,  in our example,  we did not need them
though,  but in a real world  application it's not a bad idea to  save them as
has been shown above. "argc", "argv", and "env" are exactly what the "main" of
a C program would expect them to be.

- argc [in ESI on startup] is the number of command line arguments,  where the
  path and filename of the program itself do count also, IOW argc cannot be 0.

- argv [in EDI on startup] is a near  pointer  to an array of  near  pointers,
  (terminated by a NULL pointer) pointing to one of the command line arguments
  each.

- env  [in EBP on startup] is a near  pointer  to an array of  near  pointers,
  (terminated by a NULL pointer)  pointing  to one of the  environment strings
  each.

Even if you're not dealing with C at all, this saves lots of programming work.
So the easiest way to write a startup code that calls a C _main function could
be like that;

...
          push   ds
          pop    es
          push   ebp       ; env
          push   edi       ; argv
          push   esi       ; argc
          call   _main
          mov    ah,4ch
          int    21h
...

Note that "argc", "argv" and "env" are only available to a PE executable.  For
32 bit "MZ" executables, esi, edi and ebp do not contain anything meaningful!

The remaining entry conditions for "Non- Win32 API" PE executables:

- ES = PSP selector, as usual with DPMI
- DS = SS = (alias) CS
- FS, GS undefined
- Virtual interrupts enabled
- ESP = Top of initial segment
 ( indicates the top of allocated memory = the start of your program's heap.
   Use INT 21/FFFF to expand the memory block, if needed )

The stack size on entry is at least the size of the  "Stack Commit"  parameter
in the PE .exe header.  With  TLINK32  you can specify the stack size with the
"-Sc" option, as an example.


1.2. GETTING STARTED WITH NASM
------------------------------------------------------------------------------

Your code should look as follows:

------------------------ 8< ---------------------------
[BITS 32]
[ORG 0]

     mov    ax,901h             ;enable interrupts
     int    31h

     mov    edx,hwstring        ;use extended
     mov    ah,9                ;DOS- API
     int    21h                 ;to print a string

     mov    ax,4c00h            ;terminate
     int    21h

hwstring    db 'HELLO WORLD!',0dh,0ah,'$'
------------------------ 8< ---------------------------

NASM it:        "NASM mycode.asm"
(Note that binary is the default output, at least in NASM versions up to 0.93)

WDOSX it:      "stubit mycode"

You will get a warning message. Don't be confused because of that.  There's no
way to tell a flat form binary file from a bitmap, textfile and so on...That's
what the warning is all about.

"ren mycode mycode.exe"

where "mycode.exe" will be your executable program.

WDOSX will start your program with the following entry conditions:

cs:                     guess what!
ds,ss:                  alias(cs)
es:                     selector(PSP)
esp:                    size of flatmode ovelay + 1k = initial segment size
                        dword aligned
anything else:          undefined
virtual interrupts:     disabled

"inital segment size" is the size of the  NASM  binary output file appended to
the WDOSX stub.

You may want to expand the initial  segment size later on. See the description
of INT 21/FFFF below for that matter!




1.3. GETTING STARTED WITH BORLAND DELPHI 2
------------------------------------------------------------------------------

WDOSX  has been designed to execute Turbo Pascal (DOS) style programs compiled
with the Borland Delphi 2 compiler.

The system runtime library (SYSTEM.DCU) is calling few Win 32 API functions at
runtime and WDOSX emulates just these.  Note that even while running in a DOS-
box under Windows, the WDOSX- API emulation is used.  Even in Windows,  WDOSX-
extended programs will run as true DOS- programs,  enabling your program to do
anything a DOS program is supposed to do ( calling interrupts,  writing to the
screen memory directly and so on...).

At the top of my wish list there is  support for  SYSUTILS ( parts of it ) and
structured exception handling.  In fact,  I started implementing it,  but this
hasn't quite been  finished  so please stay patient the next release will very
likely include these features!


YOU SHOULD  NEVER CALL WINDOWS API FUNCTIONS DIRECTLY FROM WITHIN YOUR PROGRAM
EVEN THOUGH IT'S POSSIBLE!

The reason is,  that sometimes they may behave a bit different and, of course,
you're writing _DOS_ programs, aren't you?

So, let's say: WDOSX is a DOS extender for "Turbo Pascal 8" a.k.a. "Delphi 2".

Howto:

- compile:               "dcc32 -CC yourprog.pas"
- make a DOS executable: "stubit yourprog.exe"

"yourprog.exe" now is a DOS- program. Easy, isn't it?

Note that you cannot just take code written for TP7 16 bit DPMI and recompile,
32 bit DPMI API requires 32 bit register passing in several places.




- What does not work, anyway?
-----------------------------


16 BIT UNITS (TPU) CANNOT BE USED!

Some may recompile as they are, some may need few modifications, some may need
beeing rewritten for 32 bit.

The problem raises if there was no sourcecode along with the TPU. What to do ?
Well, if the author is known and he's a good guy, it may help to write him/her
a few lines explaining the matter so he/she probably would be willing and able
to recompile the unit to .DCU for you.

As of the missing MEM[] there is a workaround by declaring

mem:  array[0..$7ffffffe] of byte absolute 0;{bug or feature:compiler refuses}
                                             {$7fffffff, but,who actually has}
                                             {2 gigabyte of RAM?             }
memw: array[0..$3ffffffe] of word absolute 0;
meml: array[0..$1ffffffc] of integer absolute 0;

address: integer:
value:   byte;
...
value:=mem[address];

but you'll have to modify existing 16 bit code anyway. You're unable to access
video memory directly with MEM, so there is not much use for it.

PORT[] workaround:

port[$3c7]:=b;  becomes:

asm
  mov edx,3c7h
  mov al,b	{depending on the type of b a formal type casting may}
                {be neccessary.                                      }
  out dx,al
end;


b:=port[$3c7];	becomes:

asm
  mov edx,3c7h
  in al,dx
  mov b,al
end;


What will never work?
---------------------

The  Delphi compiler does not generate FPU emulation code.  You need either an
FPU or an (32 bit) emulator to run programs that use REAL types.


What else can happen?
---------------------

- At load time you get the  message  "Unsupported dynalink"  or so. This means
  that your  program  compiles to something that uses a WIN32 API function not
  supported yet.

- At runtime you get a  message  looking like the name of a WIN32 API function
  and the program aborts.  This means your  program  called a function I never
  thought it would be called ever.

  Some API functions are implemented as phantom calls since your program wants
  to import them. However, they don't get called ever, usually...

- You get the  classic  register  dump on  screen and the program aborts. This
  means that some sort of a CPU  exception  occured  that  has  been caught by
  the DOS extender. The reason for this one could be pretty much anything.

  Some Hints:
  exception 00: the well known divide overflow
  exception 0E: most likely an attempt to access memory when there is none
                (invalid pointers and so)
  exception 0D: not very likely unless the program is executing data
                or you messed around with inline assembly (write to CS:...)

- It just bombs.  This means that  something  else went wrong and nobody has a
  clue.



1.4. GETTING STARTED WITH BORLAND C/C++
------------------------------------------------------------------------------

From the IDE,select Win32 console executable as target in your project options
and make sure to have  "static libraries"  selected  as well.  ANSI C programs
should not cause any problems.  You may want to  experiment  with the  Borland
extensions to the language. Feel free to do so and don't forget to tell me how
it works! C++ code might/might not work since there's no  structured exception
handling in WDOSX _yet_.

A good idea would be to create a "Tools" menu entry "Create DOS executable" so
anything is a matter of a few mouse clicks.

From the command line ( for a simple program ):

"BCC32 mycode.c"
"stubit mycode.exe"

As a side note: "stubit.exe" itself has been written in Borland C 5 as a Win32
application and then basically been stubbed by itself e.g.

"copy stubit.exe si.exe"    ( you cannot write to a Win32 executable when it's
                              running. )

"si stubit.exe" - "del si.exe"

Have a look at the  Delphi 2  section  above  to see what is possible with the
Win32 API emulation in WDOSX and what isn't.




2.   MORE TECH STUFF
==============================================================================
2.1. INTERRUPTS AND EXCEPTIONS
------------------------------------------------------------------------------

- If you're running in plain DOS without a DPMI host, WDOSX will install its-
- built in DPMI host. The following section describes the behaviour of the  -
- WDOSX DPMI host in certain situations. While running under Windows etc.   -
- things are depending on the DPMI host the system provides.                -


If a protected  mode IRQ handler has been installed by your program,  hardware
interrupts  occuring  in real mode or V86 mode are  passed up to it. Otherwise
thereal (V86) mode handler is called.

WDOSX can  handle a  maximum mode switch nesting level of 16.  This may be im-
portant to know  when doing  mode switches  from within an IRQ handler or even
allowing an IRQ handler to be interrupted again.

All software interrupts up to 0Fh are  interpreted  as exceptions, so doing an
INT 5 to invoke the  printscreen handler will trigger a bounds check exception
instead. You may want to use the DPMI translation  services to get INT 5 doing
the expected things.

Unlike the DPMI spec says, exceptions 0..7 are not passed down to realmode.

If an exception  handler has been installed by your program, it will be called
in a DPMI compliant manner.  Otherwise  the  default  handler  will  take over
control, causing the register dump and program abortion as usual.

Because your program is running on privilege level 0 when WDOSX  installed its
own DPMI host,  there will be no  stack  switch  done by the CPU  itself if an
exception occurs.  This will cause the  system to crash with a triple fault if
your  program's  stack is corrupt at this point.  Most stack faults will crash
the machine either.

Exception 0F will be passed down to real mode under  any  cirmstances. This is
because of a nice feature of the interrupt  controller beeing able to generate
spurious IRQ 7's.


2.2. MEMORY LAYOUT
------------------------------------------------------------------------------

If WDOSX is  running its built in DPMI host,  the initial linear start address
of your program's memory block is 400000h. Under Windows etc. it can be pretty
much anywhere so don't make assumptions here.

At startup, ESP will  point to to the top of the  memory block,  IOW accessing
the memory location at  [esp]  will be an invalid  operation  that may cause a
page fault, while accessing [esp-4] (by pushing a value etc.) is fine.

The cs: ds: (= ss:)  descriptors  are initialized with a limit of 4G. However,
Windows NT 3.5, for instance, does alter the descriptor limits internally. So,
if you like to know the true limits, use the LSL instruction.

Some documentations do recommend the use of negative offsets for accessing the
video memory or any other memory region in the first megabyte.  Be warned that
there are some pitfalls with this method.   The DPMI host is allowed to change
the linear base address of your segment if you resize it.  So, your previously
calculated  negative offsets will become  invalid and you need to  recalculate
them.  A more  hassle  free variant is to  allocate  a  descriptor with a base
address of 0 and a limit of 4G that'll let you access  virtually  anything you
want.

Never call  INT 31/0503 to resize the segment you're currently running in!  To
keep you away from doing this with your initial segment, I just don't tell you
the handle the DPMI host returned when WDOSX allocated the memory block.

WDOSX provides an easy to use API function  (INT 21/FFFF) that lets you resize
your initial segment. It MUST be called from within your initial segment, too!
Well, it isn't a good idea to have more than one DPMI memory block either,  so
what? (The debugger uses two of them, but this is another issue.)



3. THE WDOSX API
==============================================================================

The WDOSX API could be divided into 3 parts:

- DPMI 0.9 API
- Extended INT 21H DOS API
- Proprietary functions

Currently, almost all DPMI functions as described in the DPMI0.9 specification
are supported by WDOSX.

If you're not familar with DPMI, pull the spec from:

ftp://x2ftp.oulu.fi/pub/msdos/programming/specs/dpmispec.arj

The  extended INT 21H is  implemented  in a way similar to other DOS extenders
that provide an extended INT 21H DOS API.


3.1. DPMI 0.9 API functions NOT supported:
------------------------------------------------------------------------------

- RAW MODE SWITCH, SAVE/RESTORE STATE AND STUFF

             Hate to say that but: I didn't need that as of today.
             There are, of course, raw mode switch procedures in the kernel
             and it wouldn't be a big deal to write the interface for them...
             Hmm... maybe next release.


- ALLOCATE SPECIFIC LDT DESCRIPTOR:

             Err... hmmm... this one will never get into WDOSX, because while
             running in RAW/XMS/VCPI mode, we do not have a LDT, everything
             is in the GDT, thus the selectors specified for this function to
             be free actually aren't.

             Who cares?


3.2. DPMI- 0.9- functions supported by WDOSX
-------------------------------------------------------------------------------

LDT- MANAGEMENT:

0000	ALLOC LDT DESCRIPTORS
0001	FREE LDT DESKRIPTORS
0002	SEGMENT -> SELECTOR
0003	GET SELECTOR INCRMENT
0006	GET SEGMENT BASE
0007	SET SEGMENT BASE
0008	SET SEGMENT LIMIT
0009	SET ACCESS RIGHTS
000A	CREATE ALIAS
000B	GET DESCRIPTOR
000C	SET DESCRIPTOR

DOS- MEM:

0100	ALLOC DOS- MEM
0101	FREE DOS- MEM
0102	MODIFY DOS- MEM

INTERRUPTS:

0200	GET REALMODE INTERRUPT VECTOR
0201	SET REALMODE INTERRUPT VECTOR
0202    GET EXCEPTION HANDLER
0203    SET EXCEPTION HANDLER
0204	GET PM INTERRUPT VECTOR
0205	SET PM INTERRUPT VECTOR

TRANSLATION SERVICES:

0300	SIMULATE REAL MODE INTERRUPT
0301	CALL REALMODE PROCEDURE (RETF)
0302	CALL REALMODE PROCEDURE (IRET)
0303	ALLOCATE REALMODE CALLBACK
0304	FREE REALMODE CALLBACK

VERSION:

0400	GET DPMI VERSION

MEMORY MANAGEMENT:

0500	GET FREE MEM
0501	ALLOC MEM
0502	FREE MEM
0503	RESIZE MEM

VIRTUAL MEMORY MANAGEMENT:

0600	LOCK LINEAR REGION
0601	UNLOCK LINEAR REGION
0602	UNLOCK REALMODE REGION
0603	RELOCK REALMODE REGION
0604	GET PHYSICAL PAGE SIZE

DEMAND PAGING:

0702	MARK PAGE PAGEABLE
0703	DISCARD PAGE

PHYSICAL MEMORY:

0800	MAP PHYSICAL REGION

VIRTUAL ITERRUPTS:

0900	GET AND DISABLE VI STATE
0901	GET AND ENABLE VI STATE
0902	GET STATE



3.3. Extended DOS INT 21H API			
------------------------------------------------------------------------------

..............................................................................
21/09 - DOS- write string to console
..............................................................................

DIFFERENCES WDOSX/DOS:

- DOS uses DS:DX, WDOSX uses DS:EDX

..............................................................................
21/39 - DOS- MKDIR
..............................................................................

DIFFERENCES WDOSX/DOS:

- DOS uses DS:DX, WDOSX uses DS:EDX

..............................................................................
21/3A - DOS- RMDIR
..............................................................................

DIFFERENCES WDOSX/DOS:

- DOS uses DS:DX, WDOSX uses DS:EDX

..............................................................................
21/3B - DOS- CHDIR
..............................................................................

DIFFERENCES WDOSX/DOS:

- DOS uses DS:DX, WDOSX uses DS:EDX

..............................................................................
21/3C - DOS- create
..............................................................................

DIFFERENCES WDOSX/DOS:

- DOS uses DS:DX, WDOSX uses DS:EDX

..............................................................................
21/3D - DOS- open
..............................................................................

DIFFERENCES WDOSX/DOS:

- DOS uses DS:DX, WDOSX uses DS:EDX

..............................................................................
21/3F - DOS- read
..............................................................................

DIFFERENCES WDOSX/DOS:

- DOS uses DS:DX, WDOSX uses DS:EDX
- DOS uses CX = bytes to read, WDOSX uses ECX
- DOS returns AX = bytes read, WDOSX returns EAX = bytes read

This means: YES! You _can_ read more than 64k at once!

..............................................................................
21/40 - DOS- write
..............................................................................

DIFFERENCES WDOSX/DOS:

- DOS uses DS:DX, WDOSX uses DS:EDX
- DOS uses CX = bytes to write, WDOSX uses ECX
- DOS returns AX = bytes written, WDOSX returns EAX = bytes written

This means: YES! You _can_ write more than 64k at once!

..............................................................................
21/41 - DOS- delete
..............................................................................

DIFFERENCES WDOSX/DOS:

- DOS uses DS:DX, WDOSX uses DS:EDX


..............................................................................
21/43 - DOS- get/set file attribute
..............................................................................

DIFFERENCES WDOSX/DOS:

- DOS uses DS:DX, WDOSX uses DS:EDX

..............................................................................
21/47 - DOS- get current directory
..............................................................................

DIFFERENCES WDOSX/DOS:

- DOS uses DS:SI, WDOSX uses DS:ESI

..............................................................................
21/4E - DOS- find first matching file
..............................................................................

DIFFERENCES WDOSX/DOS:

- DOS uses DS:DX, WDOSX uses DS:EDX

Note: On startup the DTA is at ES:80h since ES is loaded with the PSP selector.

..............................................................................
21/56 - DOS- rename
..............................................................................

DIFFERENCES WDOSX/DOS:

- DOS uses DS:DX, WDOSX uses DS:EDX
- DOS uses ES:DI, WDOSX uses ES:EDI

..............................................................................
21/5A - DOS- create temporary file
..............................................................................

DIFFERENCES WDOSX/DOS:

- DOS uses DS:DX, WDOSX uses DS:EDX

..............................................................................
21/5B - DOS- create new file
..............................................................................

DIFFERENCES WDOSX/DOS:

- DOS uses DS:DX, WDOSX uses DS:EDX



3.4. PROPRIETARY WDOSX FUNCTIONS
------------------------------------------------------------------------------

..............................................................................
INT21H     AX = FFFFH: RESIZE FLAT SEGMENT
..............................................................................

THIS IS A PROPRIETARY FUNCTION, NOT A DOS- FUNCTION!

ON ENTRY: EDX = NEW SIZE
RETURNS : CF CLEAR ON SUCCESS, CF SET: ERROR, NOTHING DONE

This one is needed because with  INT 31H you cannot resize the segment you are
currently running in.  Using this call, you can.  But NOTE:  This call assumes
to get called from your initial flat segment, don't call from anywhere else!

USAGE:

 mov ax,0ffffh
 mov edx,400000h           ; new size = 4 MB, just an example
 int 21h
 jc what_the_hell_happened ; should only happen if there's not enough memory
 mov esp,edx               ; adjust stack pointer on top of segment. This is
                           ; not necessary, but a usual way to deal with the
                           ; stack if there's nothing pushed onto it yet.




Enjoy!

Leipzig, 16.03.1997
Michael Tippach a.k.a. Wuschel
