Dec 062017
Everything You Need To Start Coding In 386 Protected Mode Assembly. An Update Of Our Old START32 Code, It Also Includes Many Helpfulines And Examples To Start You Off. The Libraries Include File I/O, Command Line Parsing,

Full Description of File

- Renaissance 1993 Presents

Everything You Need To Start Coding
In 386 Protected Mode Assembly. An
Update Of Our Old START32 Code, It
Also Includes Many Helpful Routines
And Examples To Start You Off. The
Libraries Include File I/O, Command
Line Parsing, And Advanced Keyboard
Handling. Many Bugs Fixed Since The
Last Release! Get Out Of The Stone
Age And Start Using Your 386 PC To
Its Fullest Potential!

File CODE32.ZIP from The Programmer’s Corner in
Category Assembly Language
Everything You Need To Start Coding In 386 Protected Mode Assembly. An Update Of Our Old START32 Code, It Also Includes Many Helpfulines And Examples To Start You Off. The Libraries Include File I/O, Command Line Parsing,
File Name File Size Zip Size Zip Type
ARGC32.ASM 4665 908 deflated
ARGC32.INC 91 45 deflated
CBTMEM.EXE 15257 3573 deflated
CODE.DOC 12944 4985 deflated
COPYMEM.RT 679 237 deflated
DEL.RT 858 288 deflated
EXAMPLE0.ASM 2351 696 deflated
EXAMPLE1.ASM 1703 588 deflated
EXAMPLE2.ASM 1702 524 deflated
EXAMPLE3.ASM 1667 542 deflated
EXAMPLE4.ASM 6209 1597 deflated
FILE32.ASM 11197 1704 deflated
FILE32.INC 240 105 deflated
FILE_ID.DIZ 615 343 deflated
H.ASM 1147 197 deflated
HEXB2BCD.RT 619 195 deflated
HEXW2BCD.RT 907 208 deflated
INDXBYTE.RT 732 267 deflated
INDXWORD.RT 733 274 deflated
INS.RT 842 290 deflated
KB32.ASM 6737 1452 deflated
KB32.INC 689 329 deflated
PDOSSTR.RT 790 272 deflated
PUTNUMTM.RT 805 265 deflated
REN-93.NFO 3504 1191 deflated
SQRT.RT 1512 485 deflated
START32.ASM 25165 4457 deflated
START32.DOC 14572 5208 deflated
START32.INC 952 322 deflated
STRCAT.RT 614 207 deflated
STRCMP.RT 687 237 deflated
STRCPY.RT 499 176 deflated
STRHTN.RT 607 235 deflated
STRLEN.RT 477 171 deflated
STRLTU.RT 652 224 deflated
TPCREAD.ME 199 165 deflated

Download File CODE32.ZIP Here

Contents of the CODE.DOC file

Intro crap:

Hello coder... This is Tran typing... What have you got here??? Well, the
ASM files that were so conveniently included with this doc, are most of the
stuff you will need to begin coding in full protected mode of the 386+...
Included are file routines, getting command line argumets, a low level
keyboard handler, of course the protected mode header, and a little utility -
CBTMEM - that you use on your EXEs to give them the ability to reboot any
system infested with evil memory managers and the like so that your superior
protected mode program may run undaunted by their lameness...

I coded all this stuff for my own personal use, but give this now to you
so that you may enjoy the total coding freedom of flat memory, totally under
your control... The hardest thing of course, was the header itself - START32.
There is almost no info out there on the mundane little things that you need
to do to set the system up for protected mode ... Like enabling the A20, or
reprogramming the IRQ handlers... Even now, the info I have is incomplete. But
it is good enough to run on almost all systems.

Protected mode:

I find it sad that protected mode should be limited to technical things
like "QEMM" or "Windows"... Anyone with a 386+ and good old regular DOS can
take advantage of all that pmode has to offer... And thats what this code
will help you to do... With this code, you can write full 32bit pmode crap,
with nothing like the 64k, 640k, or 1M barriers to hinder you. If you don't
code in assembler however, go no further, because this code will do you no
good unless you are fluent in (and of course you have love of) assembly...
And if you have never used the 386 instruction set before, then youre in for
a treat. I suggest however that you get yourself a good book on the 386,
because this doc can't explain everything for you...

Files included:

START32.ASM - Header code for getting in and out of, and handling protected
START32.INC - All extrns and macros you need to access various features
of START32 from your module.
START32.DOC - Old doc on technicalities of START32.
FILE32.ASM - Library of some file functions.
FILE32.INC - All extrns for FILE32.
ARGC32.ASM - Three functions for getting command line parameters.
ARGC32.INC - All extrns thereof (or whateverin, or howevercrap,
or something).
KB32.ASM - Low level keyboard driver.
KB32.INC - Extrns, and one solitary 1 instruction macro.
H.ASM - Blank generic header file thing.
EXAMPLE?.ASM - Bunch of example programs.
*.RT - Misc routines you can use.
CBTMEM.EXE - Turns your EXEs into self-rebooting-then-running-again
thingys so that people dont have to mess with their configs

and various other little annoying pieces of propaganda for any and all
boardz this file has been through. (Except of course for our own propaganda,
which is OK).

Ok, now what?:

First thing's zeroth... Read START32.DOC, its a doc from the old released
START32, with minor changes for time. If you are interested here are the
annoying little bugs that were in that old release:

) The A20 enabling was far from perfect.
) There was no permission bitmap in the TSS for ports above 400h.
) A really really really stupid typo in the _getmem function.
) Problems with EXEs over 64K
) I forget what else...

Now that you read that:

I suggest you boot into a clean configuration (no memory managers or crap),
then compile EXAMPLE0 and START32. Compile with multiple passes and case
sensitivity on symbols (I'm assuming youre using TASM and TLINK). Then link
and run the program you just created, if only to make sure it runs on your

I don't know how much experience you've had with TASM or TLINK, so just in
case you don't know, heres how you would do this:


I'm assuming it ran:

And if it didn't... It's not my fault... Cuz it runs here...

Anyways... now:

To use the libraries, you would compile them, and link them in with your
module and START32. You would also include the .INC files of the libraries
you will be using in your module to make its functions and data areas
available to your program.


This is a basic library of some file functions. They are:

_openfile - I think this is self-explanatory.
_readfile - ditto.
_writefile - gee... what could this possibly be???
_createfile - I don't know...
_deletefile - summons the devil...
_findfile - ok, this one is the same as DOS int 21h functions 4eh, and
4fh (AL specifies which one upon entry).
_lseekfile - same as int 21h function 42h.
_filesize - returns the size of and opened file.
_filecopy - copies ECX bytes from one open file to another.
_closefile - guess...

To get a slightly better understanding of these functions, check out FILE32
itself, and check out some of the example programs that use FILE32.

Most of the functions will work immediately, without any setting up of
anything by your program. However ... If you wish to read to a memory address
physically above 1M, or write from there, you will have to set up an
intermediate file buffer somewhere below 1M for FILE32 to use (Remember, plain
DOS can't talk to memory above 1M)... Also, '_filecopy' always requires this
buffer. But this is no problem, setting up this buffer is easy. There are two
variables that specify the location and size of this buffer. '_filebufloc' is
a pointer to the buffer area somewhere in low memory, your program must
initialize this pointer, but you may modify it to point to a default area
within your code. But why would you possibly want to do this? '_filebuflen' is
the length of this buffer. 4000h bytes by default, but you may change it at
compile time and run time.

One thing to note. At the top of FILE32, there are several lines commented
out. If you wish to use a function other than '_closefile', you must uncomment
that file's token string in FILE32 before compiling it. This is merely because
I don't like to waste code space, and include only what has to be included.
If you don't want to bother, simply uncomment all these lines, and leave it
like that, and all these functions be available without you having to edit
FILE32 every time you want to use it.


This lets you check command line argumets and switches. There are three

_cchekswitch - Checks for the presence of character AL preceeded by either
a '-' or a '/' on the command line. This function is case
sensitive, '_cchekswitchnc' is the same function, except
that it is NOT case sensitive.
_cchekstr - Gets a string from the command line. AL specifies which
string, 0 is the first, 1 is the second, etc...
_ccheksstr - check for the presence of a string IMMEDIATELY following
a switch (such as '-ftest.doc'). This function is case
sensitive on the switch.

This little library also has token strings at the top for specifying wether
to compile the functions or not.


This is my low level keyboard interface thing. It replaces the BIOS int 16h
keyboard handler (You can use the BIOS if you prefer... but WHY???). This
thing ignores the CTRL-ALT-DEL sequence, and any other annoying little
keypresses that the BIOS uses... But the best thing is, it allows you to
specify your own handler for raw keyboard input. KB32 will handle talking
to the keyboard controller, and can pass the value it reads on to your own

'_kbhand' is a pointer to the routine which will recieve the keyboard data.
It points to a function in KB32 by default. That function processes the key
code, and allows you access to the data like the BIOS. With the macro '@kbhit'
you can check to see if a key was hit, and the function '_getch' returns
the most recent keystroke (There is no keyboard buffering, (why bother)).
One advantage of this handler over the BIOS, is that it returns the shift
states along with the keypress. AL is the key pressed, and AH is the shift
state returned (check out KB32.INC for bit assignments). The character recieved
which is returned in AL, is not case adjusted. That is, if SHIFT is being held
down, and you hit 'a', lower case 'a' will be returned, and not 'A'.

If you do replace the default handler pointed to by '_kbhand' (You can do
that at run time or compile time). Your must observe these rules in your

) Your handler is being called out of an IRQ handler.
) DS and ES are set to their appropriate values, but FS and GS are not.
) AL contains the raw keyboard code.
) You may destroy EAX,EBX,ECX,EDX,ESI,EDI,EBP,DS,ES,FS, and GS.

Before using the keyboard handler, you must initialize it with the function
'_init_kb'. And before your program quits to DOS, you must call '_reset_kb'.

If you set your own handler through '_kbhand', and you want to restore the
default KB32 handler, use the function '_reset_hand'.


There are a bunch of filez with the extention '.RT'... These are just misc
routines you can include in your module to do little things. If ya want to
know what they do load 'em up and check 'em out... Some of the example programs
put them to some use.


As a consequence of being a full-fledged protected mode program, the EXEs
you create cannot run under any other memory managers that run the system in
protected mode. Thus was born CBTMEM. You use this program on your .EXE files.
CBTMEM puts a special header into them. This header detects if the system is
running under the control of some other protected mode program. If the system
is under the control of a memory manager, or something more evil, the user
will be asked if he/she/it wants to try a clean boot. If they select yes,
AUTOEXEC.BAT and CONFIG.SYS will be backed up on the root directory of the
boot drive, and replaced with something k00ler. Then the system will reboot.
The FIRST thing that is done after the reboot, is that the AUTOEXEC.BAT and
CONFIG.SYS are restored ... Thus minimizing the possibility of any unnice
things happening. Then the system will switch to the drive and directory of
the program that was run, and it will be ran again. The command line arguments
are not preserved however. After the program terminates, the user will be
asked if he/she/it wants to reboot back into their original configuration.

There are three things you put on the command line of CBTMEM.

1) The EXE you want to make self-booting (with the .EXE extention).
2) The minimum amount of low memory needed to run the EXE.
3) The minimum amount of extended memory needed.

The low memory is there for this reason: Whenever people run things, their
system is usually full of useless crap which just hogs memory, and if they
dont have enough memory to run a program, they usually have to reboot anyway.
You can have your EXE reboot for them if they don't have enough memory. If you
don't want to reboot for that reason, simply set this number to 0. If you
do want this 'feature', put the amount of free memory your program needs
(minus its own code) in paragraphs in hex.

The extended memory is the minimum amount of extended memory your program
needs. If not enough extended memory is found, the program is not run. The
means of checking is int 15h function 88h, which means that if you have any
disk-caches or anything that is using that memory for something, it will
not be corrupted. If you specified an amount higher than 0k, and an XMS driver
is detected, the person will be given the choice to reboot. This number is
also in hex, but is in K, not paragraphs like the low memory value.

Well, thats that:

Hope you like 32bit protected mode... And I hope there aren't too many typos
in this doc...

L8r... Tran...

 December 6, 2017  Add comments

Leave a Reply