|
|
Serving the Business Basic market best |
 |
||||||||||||||||||||||||||||||||
Techtips |
|||||||||||||||||||||||||||||||||
|
Link Files and
Device Drivers
A Link File is just a PVX file to make an 'ALIAS'-name for a certain 'device' or 'file', and to connect a Device Driver to it. A PxPLUS Link File is just a very simple little
file, with three components. That's it... Link Files are just that, little files that exist on your hard disk. Like any other file, they live by the same rules. Meaning that under UNIX a Link File has a filename that is just as case sensitive as any other. Under DOS/Windows the case of the filename is irrelevant. There are three kinds of Link Files in PxPLUS . Each has a slightly different header, [PVXLNK], [PVXDEV], and [PVXAPR]. Internally PxPLUS will deal with each slightly differently. Lets talk about the Header for a second. All PxPLUS Files have a header. Keyed files have [PVXKEY] and Indexed files have [PVXIND]. When PxPLUS opens any and every file, it reads up to 512 bytes out of that file right away. It then checks if it has one of these special headers that begin with "[PVX". If it finds that the file has one of these headers, then PxPLUS knows that its one of its own files, if it doesn't... then it's someone elses, and all of these "other" files get treated as operating system files... like c:\autoexec.bat or win.com or whatever it is. If its a Keyed file, then PxPLUS treats it like one. The interpreter knows how to read its own file formats. In the case of a Link File, PxPLUS does something a little different, than it would do with say... an indexed file. Since the interpreter has read enough bytes (up
to 512 right), it has the entire Link File in memory. It then pulls the other 2
characteristics out of this Link File. Internally, PxPLUS closes the Link File. Then it opens the 'other file to open' and makes sure the name stays the same as the Link File. When it has opened that file, it calls the program (Device Driver). PxPLUS puts a '*dev/' in front of it. So the program named is always called from the 'lib/_dev' directory. Thats all a Link File is and does. It doesn't care what its name is... it doesn't
care what the name of the 'other' file to open is... it doesn't care what
program it is that you want to call, nor does it care what that program does.
When the called program exits, PxPLUS continues running your program at the
end of the OPEN() You can think of a Link File as an 'ALIAS' to another file with a supporting called program if you like. There is a utility in PxPLUS that helps you to
create these Link File, called *UCL. Keep something else in mind. When you open a file and it doesn't matter what it is, PxPLUS searches for it, opens it, and checks to see if it is one of it's own files. When you do: OPEN(1)"SALES" PxPLUS doesn't care if its a keyed file, or an indexed file or a Link File. It'll check the header, and take whatever action is appropriate to the info it finds in the header of the file you opened. I mentioned that there are three kinds of Link Files. [PvxLnk] [PvxDev] & [PvxApr]. These headers cause PxPLUS to take a slightly different action. The [PVXLNK] is used when you just want the link to point to the 'other' file, without calling a program. So you could do something like: move a SALES file to another directory or drive, and create a Link File with the original name (SALES) and with the 'other' file name portion of the link, pointing to the new location of the actual file, ie F:\DATA\SALES The [PVXDEV] header is used, when you want to open some other file, and call a program. Commonly used for printers etc. The [PVXAPR] header is used for attached printers on the auxilary ports of terminals. PxPLUS opens the 'other' file name, calls the program in question, and prints the 'PS' mnemonic to the printer. It will also issue a 'PE' mnemonic when its attempts to close the file. Keep in mind. PxPLUS could care less about any 'type' of info you think it is... it just does the few simple things. The easiest way to create these Link Files, is to use the *ucl utility. Just answer the questions. Keep in mind that when it asks for the Link File name, its going to be a REAL file, one you must be able to OPEN in PxPLUS . That means you may need to put it in a specific directory, or make sure that the file can be found using your PREFIX rules. A few examples of Link Files to Printers would
be:
The name of the link is entirely up to you. The name of the file being opened, is anything you could and must be able to open with a standard OPEN() statement. Physical ports, spooler queues, the windows printer subsytem, TCP/IP ports, ODBC links, anything. The program is whatever you want, from the '*dev'
directory...
A PxPLUS Device Driver is just a 'CALL'-program to initialize and preparate a device or file, opened on a channel. ie.: They have the same effect of you doing: OPEN(1)"/dev/lp0" Here's the thing that everyone forgets. 'OKI' is just a called program. Anything and everything can be done inside them. You can open other files, you can ask for input from the user, you can call other programs if you want... they are just called programs... whatever you can or would code can be put in them. If you load a Device Driver and look at it, such as HPLASER, or SPOOLER, you can see that there is nothing special about them. At the top of the Device Driver you'll see: DEFTTY (LFO) cols,rows or DEFPRT (LFO) cols,rows. DEFTTY and DEFPRT tell PxPLUS that the file opened is either a terminal or a printer, without this, PxPLUS thinks is just a simple file. When you do use these, then PxPLUS knows to give you the FIN() information back in either TERMINAL format or PRINTER format. It uses the cols and rows to give you some starting values to use, if you query the FIN() or the MXC(), MXL() functions. LFO and LFA are two PxPLUS variables, just like
DAY or SSN are variables. A simple Device Driver such as the '*dev/epson' or '*dev/hplaser', show you that you can define mnemonics to channels, and how to go about doing that. Remember that mnemonics are defined for a specific channel, and only exist as long as that channel is opened. You can invent and define your own mnemonics if you like ! Mnemonics are defined 'to' a channel, meaning there are only available when used on that specific channel. The MNM() function can be used to re-use mnemonics from OTHER channels. For example, you could define the 'PS' and 'PE' mnemonics for starting and stopping the aux port on a terminal, in the terminal driver. Then in your printer driver, you can re-use them from channel 0 (your terminal) and apply them to the printer channel.... good for the life of the channel and no more. There are also a couple of special mnemonics, that you can define for when a file is closed. '*C' is a mnemonic that you can set for PRINT'd escape sequences (or other PRINT style commands) to send to the channel when it is closed. '*R' is an operating system command to issue when you close the channel. One of the items currently on the wish list, is a mnemonic that can be defined that will CALL a program name given in a mnemonic, when a channel is closed. The calling of a program automatically at the time of closing is not yet available but will be soon. Then there is '*I' and '*O'. If you know what
'mapchan' is, then you understand what these two mnemonics will do for you. There is nothing that says that your called program can't close the 'file to be opened' and change it to something else. The best thing to do if you wish to do this sort of thing is to save the FID() name of the original file and the channel to variables. Then set the name back to the original using the SETFID() command. I also mentioned that you can call other programs. You can do anything you want. An example of a more complex Device Driver would be: ! My driver [ code to check for the existance of a lock file
] OPEN(PCHAN)"MYOUTPUT" [ call to a program with the mnemonic defs ] SETFID (PCHAN) PNAME$ ( yes, SETFID works on
files also !) You can do anything you want. You could build a
Device Driver that reads a file to get all of the printer characteristics from
... like the config.bbx you're used to, then read the record in, parse and set
the mnemonics, create lockfiles, put up a dialogue box and ask the user how many
copies they want. The OPT(channel) function, will return the string used in the OPT= from the open clause of any channel. You can use the OPT= in your opens, then use the OPT() function to get those parameters in your driver, parse them and put the code in the responds to whatever you want. Example: Say you have a Link File name 'LP', with the 'other' filename to open as '/dev/lp0' and the program name is 'myprog' OPEN(1,OPT="Check the paperform") "LP" <PxPLUS Internally> <Inside *dev/myprog> <PxPLUS Internally> <Processing continues> Another function that few people realize is SETDEV TSK() string This directive can load entries into the TSK()
function, the string can be anything you want. The only problem with it is that
you can't erase the entries and start over. The string can be anything,
formatted however you like. Whatever you put in you'll get back. Or you can simply make an entry in a file, then in your Device Driver you could open that file, retrieve the record that matches it, parse the %COPIES% out of the string, if it exists, substitue '-n numcopies' with it. The trick is there are no limits. You could open 100 files while in your called program, each on its own channel if you want... anything goes. If you look at the '*dev/spool' driver, it wants the 'other' file to open, to be a directory name. It then captures this directory name, closes it, builds a filename for a temporary file, and uses that original directory name from the link as the place to store those temporary spooler files. Then at the end of the driver, it builds an >lp command line, and sets the mnemonic '*R' to that os command. You can have more than one command in the *R, just separate them with a ';' just like any other os command you would do. I used this approach to create a temp file, send it to the spooler, ensuring that the spooler made its own copy of the file, and then did an 'rm' of my original temp file. The *R got run when the channel was closed, so at that time, the file was sent to the spooler, and the temp was erased. I would likely create a keyed file, with records
of LP P1 P2 etc, where one of the fields was the spooler command, or physical
port name to open, another field would be a called program to set the mnemonics
for the printer type. Then I would create Link Files of LP P1 P2 etc, using the
name of my keyed file as the 'other' name to open. I would have only one Device
Driver program. A special Device Driver is '*dev/windows'. This
one is used with PVX for Windows. The biggest thing is, it's just terminology, the
whole idea of Link Files and Device Drivers is really quite simple, because
anything goes... it's as powerful as you could ever want it to be. You can do
anything you can imagine inside a Device Driver... 'cause its just a called
program... just like any other called program.
(Original text from Gord Davey, edited and adjusted by Tino Vanholst |
|||||||||||||||||||||||||||||||||