AnsweredAssumed Answered

vrf Get a list of available functions/check if a function exists.

Question asked by VRFuser on Jul 10, 2003
If you specify the path of the kernel32.dll file, for example,
/WINNT/SYS32/kernel32.dll,  then it does'nt hang up,  if I remember it

I am also in the same boat,  which pins does this program output to??  I
need to get the output on to the parallel port's data pins to control an
IC(to write to a SPI interface).  I looked at the data pins on a scope
after running this program and I could'nt figure out how they relate to
the data.

Shawn,  this last piece of information would be extremely helpful.

Thanks for your extremely helpful program.

Vikram Boyapati
Test Engineer
Axiom Microdevices,  Inc.
2100 W Orangewood Avenue
Orange,  CA 92868

Phone: (714) 634 3827 ext 117
Fax:     (714) 634 3760

-----Original Message-----
From: Daly, Denis []
Sent: Friday, July 11, 2003 12:19 AM
To: VEE vrf
Subject: [vrf] RE: Parallel Port Access

Thanks so much Shawn.

You are deconstructing suberbly what was( unfortunaltely still is! )
us a lot of trouble.

Can you finally explain how we send data independently to the data and
control pins please?

We are not connecting up a printer to the port.

Your Open function seems to open up all 25 pins, how do we specify
particular pins? I tried running your program( without a printer
connected )
and it hangs. At present we are driving LED's, 8 red for data and 4
ones for control. Using your program we want to see the red led's light
we send data to the data pins and see the green led's light when we send
data to the control pins.

Once this works we will then control some I.C.'s, which is our ultimate

I hope I have explained myself well here.

I also hope that others are benefitting from all this and I would
like to thank Shawn for all his help.

Best regards,


-----Original Message-----
From: Shawn Fessenden []
Sent: 10 July 2003 20:30
To: VEE vrf
Subject: [vrf] RE: Parallel Port Access


> Can you explain how we change it from
> sending a text string to sending binary
> bits?

Certainly - I'll do my best. If you mean just one byte, then all you
have to
do is change Write(hDev, "I wrote this to the printer port.
"); to
Write(hDev, intToChar(<bytevalue>)); If you mean a series of bytes
not necessarily a string, then...

I'm going to assume this is VEE 5. Mainly because I have that version
can test any claims I make . First, the WriteFile and ReadFile import
definitions (in the ToFile object) change specify buffers of Int32
instead of a buffer of char objects.

The change here is in the data type being passed in to the WriteFile
function and out from the ReadFile function. It used to be string (AKA
char*). Now, it's an array of int32 (AKA long*).

Write takes an array of Int32 as input. The data buffer passed to
is a chunk of memory filled with bytes, and an int32 array isn't quite
It's a chunk of memory filled with 4-byte objects. We have to squash out
of the dead space in other words. That doesn't sound so horrible, but
Intel architecture stores these 32-bit numbers backwards. If we want to
operate with 32-bit integers in VEE and be able to use individual bytes
the API, we have to handle the reversal.

We take the first four numbers passed in to Write, reverse them, cut off
of them, then squash them together into the first element of the array
gets passed to WriteFile. If you're wondering where the second reversal
takes place, it's when VEE stores the numbers in the array. When that
happens, they're back in the right order.

Say the first four numbers you want to send out the port are 1, 2, 3 and
As hex bytes, this is 0x01, 0x02, 0x03, 0x04. In an Int32 VEE array, it
looks like this:

0x00000001, 0x00000002, 0x00000003, 0x00000004
Increasing array indices->

In VEE's *memory* (on an Intel processor, that is), the bytes look like

0x01 0x00 0x00 0x00, 0x02 0x00 0x00 0x00, 0x03 0x00 0x00 0x00, 0x04 0x00
0x00 0x00
Increasing memory addresses->

And we want them to look like this:

0x01 0x02 0x03 0x04

Confusing, huh? Anyway, take the first Int32 representation above, and
if we
chop out the dead space and shift the lest significant byte of each
of the array left by 24-bits (first), 16-bits (second), 8-bits (third)
0-bits (fourth) we wind up with one Int32 number that looks like this:


This is what we want out the port, but the Intel reverses this when VEE
stores this number so it looks like this in memory:

0x04 0x03 0x02 0x01

That's why the reversal. In the Read function, this operation has to be
reversed. When an array of Int32 is received, each element needs it's
component 8-bit bytes extracted, reversed and right-shifted into place
as a
new element in the final Int32 array that Read will deliver to the rest
the application. So much for that.

> If you had time a description of
> how your program works would also
> be helpful.

Simple. In the Win32 API (one of the subsystems that NT supports) the
CreateFile, ReadFile, WriteFile and CloseHandle functions became the
standardized, preferred way for user-mode applications to deal with
input and output. That this "device" was almost always a file is
In spite of the word "File" being in these function names, these
deal with any kind of device at all, as long as that device has a name
Windows can find in some object table somewhere. Whether that object is
the file system or not doesn't matter.

However, if the name begins with the special prefix \., it is a name
has special meaning to Windows (such as PHYSICALDRIVE) or it is the name
a device that can be found in a list of system objects called the
Object List. This list contains the names of DOS device objects such as
for instance, or the logical drive letters A: and C:. Device drivers
optionally create names in this list if they want the devices they drive
be accessible with CreateFile, WriteFile and ReadFile. Sometimes they
sometimes they don't.

At any rate, any Win32 application at all can take advantage of this I/O
service by  opening a device and writing to it and reading from it. It's
that simple. People have been programmed to believe that device I/O in
Windows NT requires all kinds of special wizardry and that's just not
True, you do need a kernel-mode device driver from the manufacturer of
device you want to talk to, but once that's installed and if it conforms
the Win32 device I/O specification, nothing special is required except
CreateFile, WriteFile and ReadFile.

The VEE program works by simply calling these Win32 API functions. The
Write, Read and Close functions are "VEE wrapper functions" who's
purpose is
to hide the unnecessary complexity of the API call from the rest of the

If I want to open a device for I/O, I don't want to be bothered with the
fact that I *must* tell CreateFile I want read/write permission, or that
*must* open the existing device, not try to create a new one, or that
sharing mode *must* be no share allowed. These are pissy little details
just get in my way. So I get rid of them by hiding them in a wrapper

It's also very convenient for returning whatever information I want. For
instance, the Read function. ReadFile returns a true or false value that
indicates whether or not the call succeeded. Well, I really don't care
that. I'd rather see it deliver to me what was read. So I structure the
wrapper function to return the read buffer. Simple.

That's all there is to it really. The VEE program doesn't really "do"
at all. It's just a framework for calling Windows. NT is a very rich and
powerful operating system and it makes sense to use it.

You are currently subscribed to vrf as:
To subscribe send a blank email to "".
To unsubscribe send a blank email to
To send messages to this mailing list,  email
If you need help with the mailing list send a message to

You are currently subscribed to vrf as:
To subscribe send a blank email to "".
To unsubscribe send a blank email to "".
To send messages to this mailing list,  email "". 
If you need help with the mailing list send a message to "".