home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
OS/2 Shareware BBS: 10 Tools
/
10-Tools.zip
/
CRAIGS.ZIP
/
CRAIGS.DOC
< prev
next >
Wrap
Text File
|
1991-04-10
|
9KB
|
253 lines
Ever tried to open a file with DosFileOpen and got confused about what byte or offset
to push when? Having trouble with screen handling? Ever wished you had an easier
way to work with numbers? I have an answer, CRAIGS.DLL contains some assembly
language routines to take the drudgery out of some of these tasks. The most notable
of all, the OpenFile function, makes opening a file under OS/2 as simple as passing
two zero (0) delimited strings to the function and letting it take care of the gory details
of opening the file.
First things, first. You may feel free to use this DLL with any of your own code whether
it be for profit or not without my permission, I wrote it with the intention of making life
easier for us. However, if you should decide to use CRAIGS.DLL with a package that
you are distributing for profit please include all the files associated this .DLL so that
others may benefit from the package as well. Lastly, a donation of $5 to the address
on the last page of this file would be greatly welcomed. You don't have to make any
donation to use the .DLL, the decision is entirely up to you. I don't think $5 is too much
to ask, try opening a file with it once, you'll like how easy it is.
Programming concerns. This .DLL was written in 100 percent Assembly, it has no
provisions as of yet for interfacing with C, it should have this capability with the next
release. Make sure you are compiling so that case is ignored, or make sure any
references made to the routines contained in the .DLL are in LOWER CASE. Declare
the routines as FAR references with an EXTRN statement. And then follow the calling
conventions laid out in this DOC file. Some of the routines make heavy use of the
stack, as many as 42 bytes in some cases, so plan accordingly.
Link with the command;
LINK myprog,,,craigs.lib;
Make sure that the file CRAIGS.DLL is in a directory in your LIBPATH so that the system
can find the .DLL when it loads your program, that's all there is to it!
What follows is an explanation of each function, you will see the function's name and
what is expected to be in the registers upon entry to each function. When references
are made to 64 bit integers, AX holds the low order word, BX holds the next and so on.
When you are asked for a pointer to a 64 bit integer, the first word pointed to should
contain the low order word and so on..
Function name: print_byte
Print a byte to the display
Input: AL holds byte to be output
Output: Byte is displayed
Function name: conv_2_asc
Converts a 64 bit integer to an ASCIIZ string
Input: AX,BX,CX,DX contain 64 bit integer
DS:SI points to a buffer to receive ASCIIZ string
Output: ASCIIZ string in buffer specified.
Function name: write_string
Writes an ASCIIZ string to the display.
Input: DS:SI pointed at ASCIIZ string.
Output: Screen group associated with process.
Function name: div_32
Performs a 64 bit by 64 bit unsigned integer divide.
Input: DS:SI far pointer to 64 bit (4 word) denominator
ES:DI far pointer to 64 bit numerator.
Output: DS:SI points to result, replaces denominator
ES:DI points to remainder, replaces numerator
Function name: mul_32
64 bit by 64 bit unsigned integer multiplication
Input: DS:SI far pointer to 64 bit multiplicand
ES:DI far pointer to 64 bit multiplier
Output: AX,BX,CX,DX hold product
Function name: asc_2_int
Converts an ASCIIZ string to a 64 bit integer.
Input: DS:SI pointing to ASCIIZ string.
Output: AX,BX,CX,DX contains 64 bit integer.
Function name: set_cursor
Sets cursor position using VioSetCurPos
Input: AX=Row
BX=Column
Output: Cursor set to position in AX:BX
Function name: get_cursor
Gets cursor position
Input: None
Output: AX=Cursor Row
BX=Cursor Col
Function name: beeper
A simple little noisemaker
Input: none
Function name: readrec
Reads specified record from a file
Input: DS:SI far pointer to a structure
Structure is laid out like this:
word, file handle
double word, record number
word, record size/bytes read on return
Buffer area for data to be read
Output: AX contains 0 if function is successful
If AX <> 0 it contains an error code
Function name: writerec
Writes specified record to a file
Input: DS:SI far pointer to a structure
Structure is laid out like this:
word, file handle
double word, record number
word, record size/bytes written on return
Buffer area for data to be written
Output: AX contains 0 if function is successful
If AX <> 0 it contains an error code
Function name: closefile
Closes a previously opened file
Input: BX should contain a valid file handle
Function name: openfile
Input: ES:DI pointer access string, DS:SI pointer filename
Output: AX = 0 if file is opened
BX = Action taken
CX = File handle
AX >= 0 if file open failed, value is error code
BX & CX don't care
If ES:DI points to a null (0) byte the defaults for open are:
Open and retain size if file exists
Fail Dos Open if the file does not exist
Read only
Deny write
Don't let child inherit handle
Return error codes, no pop-up
Write through cache
Filename is a filename
I saved the most complicated for last, even though as bad as this seems it is
still much simpler than trying to remember what all the values are for all the
required entries for opening a file. The access string is nothing more than a
series of two character mnemonics which tells the function how to open your
file. Here's an example;
access_string db 'ernfardwincpcwff',0
The mnemonics are not case sensitive, lower case or upper case is fine. There
should be no spaces in the string, unless you are creating a file and want to
pass a value for the initial file size, like so;
access_string db 'efncardwincpcwff 65535',0
The mnemonics are expected to be in a certain order, which just happens to
be the order that I am going to present them to you now. Pick the one from
each group that applies to your file, but only pick ONE from each group.
If you want to select the default for a group leave its mnemonic out of the string.
Description Mnemonic
------------------------------------------------------------------------------------------------------------------------
If the file exists:
Fail Dos Open EF ;
* Open file and retain size ER ; Group #1
Open file and truncate it ET ;
If the file doesn't exist:
* Fail Dos Open NF ;
Create File NC ; Group #2
Access mode:
* Read Only AR ;
Write Only AW ; Group #3
Read and Write AB ;
Sharing mode:
Deny Read and Write DA ;
* Deny Write DW ; Group #4
Deny Read DR ;
Deny None DN ;
Inheritance flag:
Let child inherit handle IC ;
* Don't let child inherit handle IN ; Group #5
Critical error handling:
Let OS/2 pop-up and handle errors CO ;
* Let process handle errors CP ; Group #6
Cache writing:
Lazy write CL ;
* Always write through CW ; Group #7
Disk Access:
* Filename is a filename FF ;
Filename is a disk name FD ; Group #8
* Denotes default for the group.
I hope I made that clear enough, if not drop me a note and I'll try to clean up
the explanation a bit. Opening files under a multitasking operating system
may be a chore because of all the necessary sharing and file access information
the system needs, but no one said it had to be hard. I kind of like my solution
to the problem, I hope you do too.
Things to come... As I mentioned earlier, interfacing to C is a big concern of
mine, not because I am a C programmer, but simply because I think those that
do could benefit from my creations also. Other functions will be SortIndex,
LockFile and UnlockFile.
What I am trying to create is a basic .DLL that contains all the nit-picking little
things that are a real pain to have to mess with all the time. I am certainly open
to suggestions, either drop me a note in the mail, or leave a message for me on
the OS/2 Shareware BBS. Good luck with the link library.
My address is:
Craig Morrison
3036 Chaffee Ct.
Lafayette, IN 47905
For those of you who are being kind enough to donate, I cannot be
responsible for any CASH that is mailed, send either a personal
check or a money order made out to me. I will send you the source
code in return, just my way of saying thanks.
Legal Stuff
I, as the author, make no claims to any warranty of any kind with regards
to the use of this Dynamic Link Library. While every effort has been made
to ensure that the code contained in the Dynamic Link Library works as
mentioned in this document, I shall not be held responsible for any
damages whether caused or alledged to be caused from the use of this
Dynamic Link Library.