Request Help With PB DLL Compiler 1.10

[Wildman]

I recently found an old copy of this at a yard sale
so this is my first attempt at using it.

I am trying to create a 16bit dll and I need help
on a couple of points. No help file came with it
and I have not been able to find any resources on
the web for this version.

Question about VARPTR.
My understanding is that it returns a Long which is
the actual 32bit address of the variable data. Is this
address segmented (segment:offset) or is it a protected
mode address or something else entirely?

Also I have a question about how User-Defined Types
are stored in memory. Lets say I have a UDT something
like this:

Type MyType
Element1 As Byte
Element2 As Word
Element3 AS DWord
End Type
Dim MyVar As MyType

How is the data stored in memory? I am hoping it is
stored in consecutive bytes starting with Element1
and MyVar would be 7 bytes long. Is this correct?

Also would VARPTR return the same address for MyVar
and MyVar.Element1?

Would appreciate any help,
Bruce

[Auric__]

Wildman wrote:

> I recently found an old copy of this at a yard sale
> so this is my first attempt at using it.
>
> I am trying to create a 16bit dll and I need help
> on a couple of points. No help file came with it
> and I have not been able to find any resources on
> the web for this version.
>
> Question about VARPTR.
> My understanding is that it returns a Long which is
> the actual 32bit address of the variable data. Is this
> address segmented (segment:offset) or is it a protected
> mode address or something else entirely?

Not being familiar with Win16 programming, I can't even begin to guess. For
PB/DOS 3.5 it's *just* the offset (and I don't know if PB/DLL 1 has VARPTR32
or not). From the PB/DOS helpfile:

VARPTR/VARPTR32 functions
-------------------------
Purpose: VARPTR returns the offset portion of the address of a variable.
VARPTR32 returns a 32-bit pointer to a variable as a DWORD.

Syntax: y = VARPTR(variable)
y??? = VARPTR(variable)

'variable' is any numeric or string variable or an element of an array.
VARPTR of a string variable returns the offset of the location of the
string's handle, not its contents (use STRPTR to get this). VARPTR32
of string variable returns the 32-bit address of the string's handle,
not its contents.

> Also I have a question about how User-Defined Types
> are stored in memory. Lets say I have a UDT something
> like this:
>
> Type MyType
> Element1 As Byte
> Element2 As Word
> Element3 AS DWord
> End Type
> Dim MyVar As MyType
>
> How is the data stored in memory? I am hoping it is
> stored in consecutive bytes starting with Element1
> and MyVar would be 7 bytes long. Is this correct?

Maybe. Depends on what alignment is used. (I assume you're familiar with such
concepts.) I'd suggest bashing together a quick test program.

> Also would VARPTR return the same address for MyVar
> and MyVar.Element1?

I rather think not, but you never know. Again, write a quick test program.

--
Right now I'm having amnesia and deja vu at the same time.
I think I've forgotten this before.
-- Steven Wright

[Wildman]

On Tue, 28 Aug 2012 05:51:13 +0000, Auric__ wrote:

> <snip>

Thanks for the reply and it's good to see your nym again.
I still pull headers from the .old group on occasion but
I haven't made any posts in quite some time.

My biggest problem is that I can't find any docs on
PB/DLL 1.10. Apparently it isn't supported any longer by
PowerBasic. I'll give you a brief history on what I'm
trying to do. <you may yawn>

Some time ago I wrote a DOS program using Magic Assembler
that will open or close any CD/DVD drive on you system.
The program uses Function 1500h and 1510h of Int 2Fh.
No problems.

Later, I wrote a similar program for win32 using VB6. It
uses the MCI api functions to do the same thing, plus it
has a tiny gui. No problems.

Next, I tried to do the same thing for win16 using VB3 and
that is where I am now. The MCI approach did not completely
work. It would only open the cd tray IF there was an audio
cd already in the drive. Once it open, it would not close.

Then I thought about trying the DOS approach. I tried a
freeware .dll that has implemented the DOS Int function.
Never got that to work. So after running across PB/DLL,
I decided to give that a try.

The problem is with the "Device Driver Request Header"
that Int 2Fh Function 1510h uses. It is a 23-byte table
that contains information that the function uses when
called. Also, in some cases the function will return info
there too. Anyway that table has to be setup at run time
with certain information at different locations. For
example, the first byte contains the length of the header,
the third byte contains the IOCTL command, the 18th byte
contains the MSCDEX command and the next 4 bytes contain
the segmented address of 18th byte. Before the function
is called the registers are set like this:
ax = 1510h
cx = drive number, 0=A, 1=B, 2=C, etc.
es:bx = segmented address of the header

I have tried using a user-defined type to create the
header and I even tried using a string but I could not
figure out how to get the addresses I needed. Hence my
question about VARPTR. Everything I tried either gave me
a GPF error or the system just froze. Then I tried doing
it all in assembly but that brought on a new set of
problems. I setup the DDRH as a standard table with labels
is this form:
! HdrLen DB 17h
! SubUnit DB 0
! CmdCode DB 0
! DevStat DW 0
! etc.
When I tried to compile it, I got an error telling me
that assembler variables must be defined and it pointed
to "! HdrLen DB 17h". This is not a variable, it is
a label. So far I haven't found a solution for this. I
know that the compiler's assembler accepts the standard
Intel instruction set syntax but I can find no mention of
the assembler's syntax. Is it like MASM, NASM or does it
have it's own?

Did I say "brief" history? <sheez> So, what have you
been up to?

<Wildman>

[Auric__]

Wildman wrote:

> On Tue, 28 Aug 2012 05:51:13 +0000, Auric__ wrote:
>
>> <snip>
>
> Thanks for the reply and it's good to see your nym again.
> I still pull headers from the .old group on occasion but
> I haven't made any posts in quite some time.

Same here. Also the .dos group. I haven't monitored the mailing list in...
hmm... years. (It goes to my Yahoo! account, which silently files them
away.)

I'm most active in alt.hacker and microsoft.public.excel.programming
currently.

> My biggest problem is that I can't find any docs on
> PB/DLL 1.10. Apparently it isn't supported any longer by
> PowerBasic. I'll give you a brief history on what I'm
> trying to do. <you may yawn>

[snip history]

> Did I say "brief" history? <sheez>

My only suggestion would be to try it the way you did it for DOS. Win16
relies on DOS for at least *some* of the hardware stuff. (But I don't
really know anything about either, as far as talking to hardware goes.)

> So, what have you been up to?

Work, mostly. Trying to keep the stress down; have had things going on
that could make my head explode. How about you?

--
- How did you get here?
- I flew. These wings aren't just for show, you know.

[Wildman]

On Wed, 29 Aug 2012 05:21:45 +0000, Auric__ wrote:

> Wildman wrote:
>
>> On Tue, 28 Aug 2012 05:51:13 +0000, Auric__ wrote:
>>
>>> <snip>
>>
>> Thanks for the reply and it's good to see your nym again. I still pull
>> headers from the .old group on occasion but I haven't made any posts in
>> quite some time.
>
> Same here. Also the .dos group. I haven't monitored the mailing list
> in... hmm... years. (It goes to my Yahoo! account, which silently files
> them away.)

Yea I haven't been monitoring lately either. Guess we both need to play
catch-up.

>
> I'm most active in alt.hacker and microsoft.public.excel.programming
> currently.

I might checkout alt.hacker, sounds interesting.

>
>> My biggest problem is that I can't find any docs on PB/DLL 1.10.
>> Apparently it isn't supported any longer by PowerBasic. I'll give you a
>> brief history on what I'm trying to do. <you may yawn>
> [snip history]
>> Did I say "brief" history? <sheez>
>
> My only suggestion would be to try it the way you did it for DOS. Win16
> relies on DOS for at least *some* of the hardware stuff. (But I don't
> really know anything about either, as far as talking to hardware goes.)

Yea, I agree the DOS approach appears the most promising. I just need
to figure out the header thing. I was looking through the manual for
MASM 6.1 when I ran across the STRUCT keyword. I wasn't familiar with
it because 99% of the assembly programming I have done has been with
a micro assembler. For what little I have used MASM, I didn't require
many of the "macro" features. Anyway, I tried the STRUCT but PB/DLL
tells me that I have an assembler syntax error. I tried different
variations of the syntax but nothing worked. I believe that PB/DLL
supports STRUCT or something like it because I moved the structure
out of the SUB and placed it in the declarations section just to
try it. The compiler said that "data structures" must be placed within
a SUB or FUNCTION. So it seems that PB/DLL at least knows what it
is. I just have to get the syntax right.

>
>> So, what have you been up to?
>
> Work, mostly. Trying to keep the stress down; have had things going on
> that could make my head explode. How about you?

I retired the first of this year or rather semi-retired. I still work a
couple days a week at the station as master control operator. I enjoy it
so I keep doing it. The rest of my time, other than honey-do's, is spent
with my hobbies - music and programming.

<Wildman>