VBDOS + Overlays

[news.microsoft.com]

Hi

This is saga on linkers

1) I am visting a client as a consultant who has a vast program built using
VBDOS + Overlays. He was using the linker that comes with VBDOS Professional
1.0
It has got to the point where if he added a function to his program, it
would fail to link.
He assumes that he is running into some limit (pretty reasonable)

2) At that point I suggested downloading the last 16-bit Microsoft linkier,
that one that comes with Visual C++ 1.52c from Microsofts FTP site.
This worked.Whatever limit was with VBDOS Professional 1.0 seemed to go.
But the snag is found was that this eats 48 bytes of string space per
overlay, everytime one was introduced (I suspect this linker limit was also
present in the VBDOS 1.0 linker)

I also found out about the dynamic overlays and Microsoft MOVE technology
for the first time.
But I am really uncertain as to whether the linker is using the old system
of overlays or the new MOVE system (how can you tell from the MAP file?)
You see the linker response file is in the old format which is what makes me
think the old system is being used.
It does not match the FUNCTION layout in the Microsoft MOVE example.

3) At this point he bought BLINKER 7.0. On using this, it produces a
program. Links okay, no messages.
But the program just dies on the command line.
Literally you can type the name of the executable and it immediately
returns. Any code at the start where it has PRINT "I am here", does not get
executed, so it is dying on startup.

At this point I am at the clients sight trying to sort this out

/Rant Mode On
I have had it up to here with linkers, both Microsoft's 16-bit linker and
Blinker
The map fileas are very uninformative. With Microsoft's I cannot tell if it
is using static or dynamic overlays (and the map file does not say).
With Blinker, I have no idea, (yet) why the executable dies.
With both, I cannot tell what libraries the linkers link from.
The Blinker documentation is weak.
It mentions about dynamic overlays but says that they are only applicable to
Clipper, not VBDOS (wonder if that was true but just a case of old
documentation not updated)
I have not seen proper BLINKER examples.
/Rant Mode Off

Any words of wisdom appreciated

Stephen Howe

[Ethan Winer]

Stephen,

Any words of wisdom appreciated <

Unfortunately I have no real wisdom to offer. But I feel for you. All I can
suggest is to try CodeView, which lets you step through the executable code.
Since you're already up against a hard size limit, there's probably no
chance of compiling with /d (debug) to step through the code in the BASIC
view. But even without /d CodeView lets you step through the ASM startup
code. Maybe that will at least help you identify where Blinker is failing,
so you can ask them for more help.

I'll also ask how well the VB-DOS code is optimized. And are you using any
compile switches that might not be necessary? Sometimes omitting one
unnecessary switch can reduce the code size enough to go from too big to
"just fits." Likewise, moving a large group of DATA statements to a disk
file might also make the difference. And so forth.

--Ethan

[news.microsoft.com]

Well I have my well-thumbed copy of "PC Magazine BASIC Techniques and
Utilities " here, so I am pretty certain all the compiler switches are at
there best (except /ah). This is one area where the client can improve
things as you well know (I also know exactly what this does as this
sledgehammer equivalent of __huge and _halloc()/_hfree() from 16-bit
Microsoft C). /G3 reduced the size by 5%.

Post by Ethan Winer
Maybe that will at least help you identify where Blinker is failing,
so you can ask them for more help.

Zero chance of that. I think Blinker is a one-man-band.
Blinker 7.0 still comes on a 3.5" disk !!!
When was the last time you got software not on a CDROM?
If you Google the Clipper language community who still use Blinker, from
what I gather, the guy who runs Blinker Inc is into cattle ranching as his
main thing (I kid you not) and just occasionally (Once a month? Once every 3
months?) checks to see if there is new Blinker business. Strange way of
running a business but maybe he is not fussed. It does not help us when we
are stuck :-(

I have made some progress. I re-read the VBDOS Professional Books, the old
overlay syntax is still supported and it says how best to arrange to set up
for dynamic overlays (and MOVE) with Microsoft link. So following that
advice.

Wish I had brought my copy of XRef with me which is sitting at home in my
3.5" disk box :-(. Not used it in 14 years.

Post by Ethan Winer
Likewise, moving a large group of DATA statements to a disk
file might also make the difference. And so forth.

It has got to the point where all strings are in a file and they are read
from disk as needed because otherwise, "out of string space".

Stephen Howe

[Ethan Winer]

Stephen,

Blinker 7.0 still comes on a 3.5" disk !!! <

ROF,L. When (maybe once a year) someone buys one of my old products I have
the decency to email them a Zip file right away. Though I do still have a
few pre-printed 3-1/2 inch disk labels...

the guy who runs Blinker Inc is into cattle ranching <

I'm into acoustics and playing the cello now. :->) But I check my email all
the time and still provide support. Not often, maybe, but customers can
still count on me.

Wish I had brought my copy of XRef with me <

Email me through my site www.ethanwiner.com and I'll be glad to send you a
fresh copy. I don't have the manual in electronic form, but I can at least
send you the program if you think it will help.

It has got to the point where all strings are in a file and they are read

from disk as needed because otherwise, "out of string space". <

Are you using EMS memory to store stuff?

--Ethan

[news.microsoft.com]

Post by Ethan Winer
Email me through my site www.ethanwiner.com and I'll be glad to send you a
fresh copy. I don't have the manual in electronic form, but I can at least
send you the program if you think it will help.

Done. I am also thinking I shall try re-linking with Watcom 10.6's linker
(i) as that supported static & dynamic overlays. Watcom 11 linker had
eliminated overlay support.
(ii) the map file was super-friendly.
The map always showed a complete list of all libraries linked with and the
full paths (useful if you have similarly named libraries but different)
The map also marked all unused functions and data in an object file with a
#, useful to prunne out dead wood
The map also marked all functions and data that were local to a module. That
was useful if progarmming in C and 16-bit large model as marking them
"static" meant the compiler would make a near call and not a far call.

Post by Ethan Winer

Post by news.microsoft.com
It has got to the point where all strings are in a file and they are read

from disk as needed because otherwise, "out of string space". <
Are you using EMS memory to store stuff?

No, not at all. Good point. Nor XMS memory.

Stephen Howe

[Ethan Winer]

Stephen,

No, not at all. Good point. Nor XMS memory. <

My book (which you said you have) has routines for that, and as I offered in
email I'll be glad to send you any other code I have around to see if that
helps.

--Ethan

[Stephen Howe]

Post by Ethan Winer
My book (which you said you have) has routines for that, and as I offered in
email I'll be glad to send you any other code I have around to see if that
helps.

Thanks for the offer Ethan.
I think at this point, my client is concentrating on putting his application
on a DGROUP diet - the root cause of his problems.

Stephen Howe

[news.microsoft.com]

Post by Ethan Winer

Wish I had brought my copy of XRef with me <

Email me through my site www.ethanwiner.com and I'll be glad to send you a
fresh copy. I don't have the manual in electronic form, but I can at least
send you the program if you think it will help.

Thanks for your help Ethan but XRef just bombs out.
I see either Error Code 7 or 14 in QMAP (I recognize these).
And this is with about 614,000 bytes available at the Win2000 prompt
(looked at maximing memory for DOS programs by configuring custom
CONFIG.NT/AUTOEXEC.NT for _DEFAULT.PIF but it is very close to maximal)
I think 896 modules is too much for it.
I might try recompiling using Far Strings and retry and give up if XREF dies
afterwards.
We have QuickPak Professional Version 4.0 (looking at the manual as I
speak).

I am tempted to try and convert the code into a DOS4GW Watcom program and
since DOS4GW can address up to 32Mb this should go away.
It would be an interesting exercise.

My friend is quite glad, in that in using the last Microsoft 16-bit linker
(Version 5.60.339 Dec 5 1994)
instead of the linker that comes with VBDOS 1.0 (Version 5.31.009 Jul 13
1992)
so some of his limits have improved. So I have helped (but not enough).

Stephen Howe

[a***@NOW.AT.arargh.com]

On Sun, 23 Oct 2005 02:27:47 +0100, "news.microsoft.com"

Post by news.microsoft.com

Post by Ethan Winer

Wish I had brought my copy of XRef with me <

Email me through my site www.ethanwiner.com and I'll be glad to send you a
fresh copy. I don't have the manual in electronic form, but I can at least
send you the program if you think it will help.

Thanks for your help Ethan but XRef just bombs out.
I see either Error Code 7 or 14 in QMAP (I recognize these).
And this is with about 614,000 bytes available at the Win2000 prompt
(looked at maximing memory for DOS programs by configuring custom
CONFIG.NT/AUTOEXEC.NT for _DEFAULT.PIF but it is very close to maximal)
I think 896 modules is too much for it.
I might try recompiling using Far Strings and retry and give up if XREF dies
afterwards.
We have QuickPak Professional Version 4.0 (looking at the manual as I
speak).
I am tempted to try and convert the code into a DOS4GW Watcom program and
since DOS4GW can address up to 32Mb this should go away.
It would be an interesting exercise.
My friend is quite glad, in that in using the last Microsoft 16-bit linker
(Version 5.60.339 Dec 5 1994)
instead of the linker that comes with VBDOS 1.0 (Version 5.31.009 Jul 13
1992)
so some of his limits have improved. So I have helped (but not enough).

If you don't need graphics or forms or ISAM, you might want to look at
BCET. But, you get windows console programs.

But, ISTR that you are using existing 16-bit libraries, which (don't /
won't / can't) work with BCET.

Also, some time back, I wrote a replacement protected mode runtime for
PDS 7.1 which allows for up to 16 meg of memory usage. However, it
has some annoying requirements (a specific DOS extender which appears
to no longer be available is one) that it may not be much use to
anybody. And, existing 16-bit real mode libraries won't work either.
If you have the correct protected mode versions - maybe. Email me
direct for more info, if interested.


A final note: BCET is not wedded to windows, it could be ported to
any 32-bit flat mode environment. A FreeBSD port is partially done.
If I could find a suitable 32-bit DOS extender, with a good SDK, it
might not take all that long to do the port to DOS.

Arargh

[Stephen Howe]

Post by a***@NOW.AT.arargh.com
Also, some time back, I wrote a replacement protected mode runtime for
PDS 7.1 which allows for up to 16 meg of memory usage. However, it
has some annoying requirements (a specific DOS extender which appears
to no longer be available is one)

<interested> And which one is that?
I say this because I use to be a member of TeamSybase and supported DOS4GW
for 7 years as part of that for Watcom C/C++/Fortran.
I have advised on DOS4GW, Causeway, PMODE/W, DOS32, Pharlap, Flashtek.
All have their strengths/weaknesses. Many are now open sourced. We are
spoilt for choice :-)

Post by a***@NOW.AT.arargh.com
that it may not be much use to anybody. And, existing 16-bit real mode

libraries won't work either.

Post by a***@NOW.AT.arargh.com
If you have the correct protected mode versions - maybe. Email me
direct for more info, if interested.

Thanks for the offer. I think my client is getting busy minimising DGROUP
usuage - which is root problem for many of the things he has been
experiencing.

Cheers

Stephen Howe

[a***@NOW.AT.arargh.com]

On Mon, 24 Oct 2005 20:52:31 +0100, "Stephen Howe"

Post by Stephen Howe

Post by a***@NOW.AT.arargh.com
Also, some time back, I wrote a replacement protected mode runtime for
PDS 7.1 which allows for up to 16 meg of memory usage. However, it
has some annoying requirements (a specific DOS extender which appears
to no longer be available is one)

<interested> And which one is that?

Pharlaps "RUN-286|DOS-extender"

The runtime will also (I think) work with the LITE-286 version but you
only get 2 meg of memory.

Post by Stephen Howe
I say this because I use to be a member of TeamSybase and supported DOS4GW
for 7 years as part of that for Watcom C/C++/Fortran.
I have advised on DOS4GW, Causeway, PMODE/W, DOS32, Pharlap, Flashtek.
All have their strengths/weaknesses. Many are now open sourced. We are
spoilt for choice :-)

Just last night I found the HX 32-bit dos extender (by Japheth). URL:
http://www.japheth.de With minimal testing, it appears that BCET
will run under it. Have yet to test on plain DOS, though.

Post by Stephen Howe

Post by a***@NOW.AT.arargh.com
that it may not be much use to anybody. And, existing 16-bit real mode

libraries won't work either.

Post by a***@NOW.AT.arargh.com
If you have the correct protected mode versions - maybe. Email me
direct for more info, if interested.

Thanks for the offer. I think my client is getting busy minimising DGROUP
usuage - which is root problem for many of the things he has been
experiencing.

Yes - my old replacement runtime does not solve that problem - it's
still 64k for DGROUP. Strings max out at @ 900k (1meg-64k) and the
rest of available memory gets used for the program and far memory.

And, of course, BCETs only memory limit is when the system runs out of
memory. :-)

[Stephen Howe]

Post by a***@NOW.AT.arargh.com

Post by Stephen Howe

Post by a***@NOW.AT.arargh.com
Also, some time back, I wrote a replacement protected mode runtime for
PDS 7.1 which allows for up to 16 meg of memory usage. However, it
has some annoying requirements (a specific DOS extender which appears
to no longer be available is one)

<interested> And which one is that?

Pharlaps "RUN-286|DOS-extender"

Ahhhh yes, I know that. Watcom supported that. You to link with 16-bit PM
OS/2 libraries.
Rational (renamed as Tenberry) had a competing product called DOS16M.
Pharlap had the misfortune of inventing an API for protected mode programs
only for DPMI 0.9 to come out and supercede it and then they had the
overhead of having to support 2 APIs (not a great bother I suspect).

Post by a***@NOW.AT.arargh.com

Post by Stephen Howe
I say this because I use to be a member of TeamSybase and supported DOS4GW
for 7 years as part of that for Watcom C/C++/Fortran.
I have advised on DOS4GW, Causeway, PMODE/W, DOS32, Pharlap, Flashtek.
All have their strengths/weaknesses. Many are now open sourced. We are
spoilt for choice :-)

http://www.japheth.de With minimal testing, it appears that BCET
will run under it. Have yet to test on plain DOS, though.

It would interesting to run DPMI conformity tests for all the extenders.
It would also be interesting to find out which ones support various DPMI 1.0
APIs
But you might be interested in some of the 32-bit DOS Extenders
Some of them have base-level support for XMS 3.0 (and not XMS 2.0). The
implications of that is they can allocate up to 4Gb.
DOS4GW (and also Tenberry's top-of-the-range extender DOS4G) only ever
supported XMS 2.0 standard which meant they were limited to 64Mb in terms of
memory allocation.

Post by a***@NOW.AT.arargh.com

Post by Stephen Howe
Thanks for the offer. I think my client is getting busy minimising DGROUP
usuage - which is root problem for many of the things he has been
experiencing.

Yes - my old replacement runtime does not solve that problem - it's
rest of available memory gets used for the program and far memory.
And, of course, BCETs only memory limit is when the system runs out of
memory. :-)

:-)

Stephen Howe

[a***@NOW.AT.arargh.com]

On Tue, 25 Oct 2005 00:04:30 +0100, "Stephen Howe"

Post by Stephen Howe

Post by a***@NOW.AT.arargh.com

Post by Stephen Howe

Post by a***@NOW.AT.arargh.com
Also, some time back, I wrote a replacement protected mode runtime for
PDS 7.1 which allows for up to 16 meg of memory usage. However, it
has some annoying requirements (a specific DOS extender which appears
to no longer be available is one)

<interested> And which one is that?

Pharlaps "RUN-286|DOS-extender"

Ahhhh yes, I know that. Watcom supported that. You to link with 16-bit PM
OS/2 libraries.

Yes. Supported (Somewhat) by QuickBasic 6, 7, & 7.10.
(And assorted versions of C)

Post by Stephen Howe
Rational (renamed as Tenberry) had a competing product called DOS16M.

Which API? - DOS or OS/2 or other? - I suppose I could find out on the
web. :-)

Post by Stephen Howe
Pharlap had the misfortune of inventing an API for protected mode programs
only for DPMI 0.9 to come out and supercede it and then they had the
overhead of having to support 2 APIs (not a great bother I suspect).

Post by a***@NOW.AT.arargh.com

Post by Stephen Howe
I say this because I use to be a member of TeamSybase and supported DOS4GW
for 7 years as part of that for Watcom C/C++/Fortran.
I have advised on DOS4GW, Causeway, PMODE/W, DOS32, Pharlap, Flashtek.
All have their strengths/weaknesses. Many are now open sourced. We are
spoilt for choice :-)

http://www.japheth.de With minimal testing, it appears that BCET
will run under it. Have yet to test on plain DOS, though.

It would interesting to run DPMI conformity tests for all the extenders.
It would also be interesting to find out which ones support various DPMI 1.0
APIs
But you might be interested in some of the 32-bit DOS Extenders
Some of them have base-level support for XMS 3.0 (and not XMS 2.0). The
implications of that is they can allocate up to 4Gb.
DOS4GW (and also Tenberry's top-of-the-range extender DOS4G) only ever
supported XMS 2.0 standard which meant they were limited to 64Mb in terms of
memory allocation.

For the moment, all I need in a DOS extender, is to support the
minimal portion of the Windows API that BCET uses, and minimal
intrusion into the program compilation process. HX seems to have
that.

<snip>

[Stephen Howe]

Post by a***@NOW.AT.arargh.com

Post by Stephen Howe
Rational (renamed as Tenberry) had a competing product called DOS16M.

Which API? - DOS or OS/2 or other? - I suppose I could find out on the
web. :-)

The DPMI spec. The DPMI spec as a combined 16/32 bit spec.
But Tenberry also provides a library oof functions which I think are just
wrapper functions around the DPMI spec.
See http://www.tenberry.com/dos16m/index.html
And after that DOS services are provided, just like real mode, because it
is, after all a _DOS_ extender.

I have never used DOS16M, just DOS4GW and family, the 32-bit equivalent.

Cheers

Stephen Howe

[a***@NOW.AT.arargh.com]

On Tue, 25 Oct 2005 03:52:48 +0100, "Stephen Howe"

Post by Stephen Howe

Post by a***@NOW.AT.arargh.com

Post by Stephen Howe
Rational (renamed as Tenberry) had a competing product called DOS16M.

Which API? - DOS or OS/2 or other? - I suppose I could find out on the
web. :-)

The DPMI spec. The DPMI spec as a combined 16/32 bit spec.
But Tenberry also provides a library oof functions which I think are just
wrapper functions around the DPMI spec.
See http://www.tenberry.com/dos16m/index.html

I did.

Post by Stephen Howe
And after that DOS services are provided, just like real mode, because it
is, after all a _DOS_ extender.

Straight PDS might work with it. Maybe. :-) PDS jacks around with
the keyboard and screen so much that it would be interesting to try.
If I had a copy. Which I don't.

And the runtime I wrote, certainly won't without major changes. If I
ever need to get it working again, I will dig around for a free
product.

Post by Stephen Howe
I have never used DOS16M, just DOS4GW and family, the 32-bit equivalent.

[news.microsoft.com]

Post by news.microsoft.com
I might try recompiling using Far Strings and retry and give up if XREF dies
afterwards.
We have QuickPak Professional Version 4.0 (looking at the manual as I
speak).

I did this.
Got PULLDNMS.BAS from QuickPak Professional.
Linked with PRO7.LIB as Far Strings.
Called it XREF2

But despite this, it died.
It got further than XREF, I could see it working but 3 modules in, it died.
This time, Error 9 in QMAP.

Sigh

Stephen Howe

[Ethan Winer]

Sigh ><

Indeed...

[news.microsoft.com]

Update:

I now know something which is screwing up the Blinker version.
Basically on linking with Blinker, it is pulling in functions from
PROISAMD.LIB despite the fact there is not a single ISAM statement in the
program. And that bumps the size up. I cannot eliminate it as Blinker
complains. So something is requesting ISAM support.

Now I know OPEN, CLOSE statements support ISAM, so how is the BC compiler
telling Microsoft LINK not to pull in items from PROISAMD.LIB ??? In other
words why doesn't LINK complain of the same thing as Blinker?

Stephen Howe

[a***@NOW.AT.arargh.com]

On Sat, 22 Oct 2005 01:59:18 +0100, "news.microsoft.com"

Post by news.microsoft.com
I now know something which is screwing up the Blinker version.
Basically on linking with Blinker, it is pulling in functions from
PROISAMD.LIB despite the fact there is not a single ISAM statement in the
program. And that bumps the size up. I cannot eliminate it as Blinker
complains. So something is requesting ISAM support.
Now I know OPEN, CLOSE statements support ISAM, so how is the BC compiler
telling Microsoft LINK not to pull in items from PROISAMD.LIB ??? In other
words why doesn't LINK complain of the same thing as Blinker?

Try linking with "NOISAM.OBJ" - stubs out ISAM code.

Which is a good idea in any event. :-)

[news.microsoft.com]

Post by a***@NOW.AT.arargh.com
Try linking with "NOISAM.OBJ" - stubs out ISAM code.
Which is a good idea in any event. :-)

NOISAM.OBJ and NOFORMS.OBJ are of use if you are building your own custom
run-time module where dependent programs do not use it.

These are of no use in the stand-alone version (/O compiler option) of the
progarms as it should not pull in any Isam or Form support.

Thanks anyway

Stephen Howe

[a***@NOW.AT.arargh.com]

On Sat, 22 Oct 2005 01:59:18 +0100, "news.microsoft.com"

Post by news.microsoft.com
I now know something which is screwing up the Blinker version.
Basically on linking with Blinker, it is pulling in functions from
PROISAMD.LIB despite the fact there is not a single ISAM statement in the
program. And that bumps the size up. I cannot eliminate it as Blinker
complains. So something is requesting ISAM support.
Now I know OPEN, CLOSE statements support ISAM, so how is the BC compiler
telling Microsoft LINK not to pull in items from PROISAMD.LIB ??? In other
words why doesn't LINK complain of the same thing as Blinker?

Also you can use any of these, as needed:

NOCGA .OBJ 137
NOCOM .OBJ 502
NOEDIT .OBJ 551
NOEGA .OBJ 164
NOEVENT .OBJ 533
NOFLTIN .OBJ 457
NOFORMS .OBJ 1,182
NOGRAPH .OBJ 700
NOHERC .OBJ 125
NOISAM .OBJ 331
NOLPT .OBJ 216
NOOGA .OBJ 124
NOVGA .OBJ 168

[news.microsoft.com]

Hrrrmmmm I understand Microsoft LINK a bit more but got nowhere:-)

The VBDOS Professional Handbook indicates that the old overlay syntax can be
used as well as new one (using SEGMENTS in a DEF file) and in either case
the MOVE technology is used.

But I am not sure this helps.
I can for example, place every overlay module in its own overlay and say
"let the MOVE technology work here, it will move things around using
caching".
But if I do so, I run afoul of the 64K limit when linking.
DGROUP exceeded !!!!

So the implications of that is that you are back to determing the
relationship between modules, which module call which others etc. In short,
the burden is back on the programmer. Dynamic overlays have not helped much,
and effectively it is back to the old static overlay system.

Seems incredibly hard to optimise large BASIC programs

Stephen Howe

[news.microsoft.com]

Post by news.microsoft.com
3) At this point he bought BLINKER 7.0. On using this, it produces a
program. Links okay, no messages.
But the program just dies on the command line.

Update:

I think I know why it is dying.

With Microsoft's linker, you can group several object modules into 1
overlay.
With Blinker you cannot. Each object file as specified between

BEGINAREA
FILE objectfile1
FILE objectfile2
:
FILE objectfileN
ENDAREA

is such that it is in it's own overlay and although the system is dynamic,
the cost-per-overlay is such that it is eating into DGROUP.
I think the final Blinker executable won't fit in DOS memory and the
Microsoft utility EXEHDR should confirm that :-(

You cannot group several object files into 1 overlay with Blinker and
reading the help file tends to confirm that.

Stephen Howe

[Stephen Howe]

Further update:

Back from visiting client.
I think when I was working late Saturday night the truth was revealed.

I did some MAP file calculations. (I should have done this first on
Thursday)
It turned out that DGROUP was 95% full. Just 3.3K free left.
It probably explains why the Blinker executable died.
Most probably, in its kernel, it needed more than 3.3K, when it could not
get that (or BASIC internals), it exited to DOS.

I relinked with SMALLERR,NOEDIT,NOCOM and it crept up to 4.5K free
When I left I had a given a picture of what was the main culprit for this to
the client.
But I was hunting for a complete list of BASIC segments - what each of them
were for (
I know intialisers & finalisers from various compiler vendors) - to get a
complete breakdown of what each was used for. Nothing on the Internet I
could find.
It would be useful if there was.

Microsoft's LINK does work, but it pretty amazing the executable works at
all with so little free DGROUP.

It would still be useful to get XREF working in some form but currently it
will not work with absolutely huge multi-module overlayed programs.

Stephen Howe

[a***@NOW.AT.arargh.com]

On Mon, 24 Oct 2005 16:28:00 +0100, "Stephen Howe"

Post by Stephen Howe
Back from visiting client.
I think when I was working late Saturday night the truth was revealed.
I did some MAP file calculations. (I should have done this first on
Thursday)
It turned out that DGROUP was 95% full. Just 3.3K free left.
It probably explains why the Blinker executable died.
Most probably, in its kernel, it needed more than 3.3K, when it could not
get that (or BASIC internals), it exited to DOS.
I relinked with SMALLERR,NOEDIT,NOCOM and it crept up to 4.5K free
When I left I had a given a picture of what was the main culprit for this to
the client.
But I was hunting for a complete list of BASIC segments - what each of them
were for (
I know intialisers & finalisers from various compiler vendors) - to get a
complete breakdown of what each was used for. Nothing on the Internet I
could find.
It would be useful if there was.

(see below)

Post by Stephen Howe
Microsoft's LINK does work, but it pretty amazing the executable works at
all with so little free DGROUP.
It would still be useful to get XREF working in some form but currently it
will not work with absolutely huge multi-module overlayed programs.

You could try to compile it with BCET, but you would have to rewrite
all the QuickPak asm routines that it uses.


(below)

This is "PREFIX.ASM" from QuickBasic 3.0. It is the only sort of a
reference to this info that I have ever found.

Not all these segments are still in use in PDS or VBDOS, and there are
new ones added. But it will give you a start. Also, running WDISASM
against the contents of the link libs will give the name of all of the
rest.

title prefix
_CODE segment para public 'BC_CODE'
_CODE ends
CSEG segment para public 'CODESG'
CSEG ends
CODE segment para public 'CODE'
CODE ends
SHELL segment para public 'CODESG'
SHELL ends
CLEAR segment para public 'CODESG'
CLEAR ends
BC_ICN_CODE segment para public 'INIT_CODE'
BC_ICN_CODE ends
BC_IDS_CODE segment para public 'INIT_CODE'
BC_IDS_CODE ends
INIT_CODE segment para public 'INIT_CODE'
INIT_CODE ends

; DSEG must come first and not be CONST or _DATA so that other
language
; obj's do not mess with the location of DSEG
DSEG segment common 'DATASG'
DSEG ends
CONST segment para public 'CONST'
CONST ends
_BSS segment word public 'BSS'
_BSS ends
c_common segment word public 'BSS'
c_common ends
DATA segment para public 'DATA'
DATA ends
BC_DATA segment word public 'BC_VARS'
BC_DATA ends
named_common segment word common 'BC_VARS'
named_common ends
BC_FT segment word public 'BC_SEGS'
BC_FT ends
BC_CN segment para public 'BC_SEGS'
BC_CN ends
BC_DS segment para public 'BC_SEGS'
BC_DS ends
COMMON segment para common 'BLANK'
COMMON ends
LAST_SEGMENT segment para public 'LAST_SEGMENT'
LAST_SEGMENT ends
DGROUP group
DSEG,CONST,_BSS,DATA,BC_DATA,BC_FT,BC_CN,BC_DS,COMMON

public __acrtused
__acrtused equ 1

end

[Dan Barclay]

Stephen,

I did a lot of work with VBDOS and overlays, but that was many moons ago. I
also wrote up a small overlay sample program and uploaded to the libs back
on Compuserve. Dunno where that might be right now, but if you need to do
overlayed links I might could find it here somewhere.

A couple of starter hints: VBDOS uses the MOVE overlay linker equivalent to
C7. VBDOS has nearly zero documentation for MOVE, but if you can find a
copy of C7 documentation it'll be of some help.

Hint two: There are several versions of LINK.exe that work with MOVE.
HOWEVER, there is exactly *one* version that works with MOVE in VBDOS.
That is the LINK.EXE that came with VBDOS.

As you surmised earlier, there is a limit on the overlay size. I don't
remember all the rules <sigh>, but they are fairly easy to live with. As I
recall there is a limit on individual overlay size, in addition to a limit
on total overlay. I seem to recall that it will keep a maximum of 3
overlays in memory at once. The overlay limits could be tinkered with
slightly by changing a startup module (in assembler) and using the alternate
.obj file for it.

You can group .obj's into overlays using a complicated command line
grouping, but the best way is to create an overlay specification file.

You can create quite large and robust programs using MOVE. Mine was around
2 megs as I recall, but ran in less than 300meg around a ton of network and
terminal emulator TSR's. MOVE was the best thing since the $tring.

re: xref, I think that program worked on a module level didn't it? I don't
think it would care about overlays or program size.

Dan

Post by Stephen Howe
Back from visiting client.
I think when I was working late Saturday night the truth was revealed.
I did some MAP file calculations. (I should have done this first on
Thursday)
It turned out that DGROUP was 95% full. Just 3.3K free left.
It probably explains why the Blinker executable died.
Most probably, in its kernel, it needed more than 3.3K, when it could not
get that (or BASIC internals), it exited to DOS.
I relinked with SMALLERR,NOEDIT,NOCOM and it crept up to 4.5K free
When I left I had a given a picture of what was the main culprit for this to
the client.
But I was hunting for a complete list of BASIC segments - what each of them
were for (
I know intialisers & finalisers from various compiler vendors) - to get a
complete breakdown of what each was used for. Nothing on the Internet I
could find.
It would be useful if there was.
Microsoft's LINK does work, but it pretty amazing the executable works at
all with so little free DGROUP.
It would still be useful to get XREF working in some form but currently it
will not work with absolutely huge multi-module overlayed programs.
Stephen Howe

[Stephen Howe]

Post by Dan Barclay
I did a lot of work with VBDOS and overlays, but that was many moons ago.
I also wrote up a small overlay sample program and uploaded to the libs
back on Compuserve. Dunno where that might be right now, but if you need
to do overlayed links I might could find it here somewhere.

Thanks for the offer . I think I am allright. :-)

Post by Dan Barclay
A couple of starter hints: VBDOS uses the MOVE overlay linker equivalent
to C7. VBDOS has nearly zero documentation for MOVE, but if you can find
a copy of C7 documentation it'll be of some help.

Yes. I saw the MOVE documentation in the VBDOS Professional manual.
The MOVE documentation is here:
http://msdn.microsoft.com/archive/default.asp?url=/archive/en-us/dnarvc/html/msdn_draft3.asp

Post by Dan Barclay
Hint two: There are several versions of LINK.exe that work with MOVE.
HOWEVER, there is exactly *one* version that works with MOVE in VBDOS.
That is the LINK.EXE that came with VBDOS.

That was not the client's experience.
The last version of 16-bit LINK that comes with 16-bit Microsoft C, version
1.52c was a definite improvement.
My client found that VBDOS's LINK would fail and the later LINK would
succeed.
That last version of LINK had quite a few bugs fixed, bugs still present in
VBDOS 1.0's LINK.
You can get this version from here
ftp://ftp.microsoft.com/Softlib/MSLFILES/LNK563.EXE
I will lay hands that the tools that come with 1.52c are likely to be at the
most bug free they are ever likely to be.
Microsoft stopped working on 16-bit technology after this.
So NMAKE from this, LIB from this, LINK from this etc will be the best you
can get.

According to the VB documentation, MOVE supported old specification with
linker response file and new specification with a DEF file specifying the
SEGMENTs (like a 16-bit Windows program).
I could not get old new specification to work, the linker would blow up.
In contrast the old system using (, ) and +'s worked no problem.

Post by Dan Barclay
As you surmised earlier, there is a limit on the overlay size. I don't
remember all the rules <sigh>, but they are fairly easy to live with. As
I recall there is a limit on individual overlay size, in addition to a
limit on total overlay. I seem to recall that it will keep a maximum of 3
overlays in memory at once.

It is not quite that.
The Overlay Area is set to the sum of the size of the 3 largest OBJ's if
possible. Otherwise the largest OBJ.
As many overlays as possible will be in a cache principle basis.

Post by Dan Barclay
The overlay limits could be tinkered with slightly by changing a startup
module (in assembler) and using the alternate .obj file for it.

See Move documentation. You can control things with ENV variables.
I found moveinit inside VBDCL10E.LIB but did not disassemble it to see if it
conformed to the online documentation.

Post by Dan Barclay
You can group .obj's into overlays using a complicated command line
grouping, but the best way is to create an overlay specification file.

If you means a linker response file, that is what the client had.
If you mean a DEF file with SEGMENT definitions (what the VBDOS
documentation recommended: could not get it to work)

Post by Dan Barclay
re: xref, I think that program worked on a module level didn't it? I
don't think it would care about overlays or program size.

Nope. With XREF, you fed it a MAK file, which has a complete list of all the
BAS files.
I wanted to use XREF to find unused variables and that means you _must_ feed
it everything.
At about 900 modules, it was too big for XREF, even compiled with Far
strings :-(
I will try relinking with Watcom's WLINK from 10.6. That supported static
and dynamic overlays and in particular, the MAPs were the best of any
linker. The MAPs revealed unused symbols. It also support CodeView debugging
info. I will see if I can get progress here.

Cheers

Stephen Howe

[Dan Barclay]

Post by Stephen Howe

Post by Dan Barclay
I did a lot of work with VBDOS and overlays, but that was many moons ago.
I also wrote up a small overlay sample program and uploaded to the libs
back on Compuserve. Dunno where that might be right now, but if you
need to do overlayed links I might could find it here somewhere.

Thanks for the offer . I think I am allright. :-)

Post by Dan Barclay
A couple of starter hints: VBDOS uses the MOVE overlay linker equivalent
to C7. VBDOS has nearly zero documentation for MOVE, but if you can
find a copy of C7 documentation it'll be of some help.

Yes. I saw the MOVE documentation in the VBDOS Professional manual.
http://msdn.microsoft.com/archive/default.asp?url=/archive/en-us/dnarvc/html/msdn_draft3.asp

I'm glad to see some things have changed. Finding information on MOVE,
other than a conceptual whitepaper and a few command line switches, was
quite difficult in the beginning. We had to beg them for info on moveinit
at the time! They didn't want to give it to us but finally did. The rest
we had to noodle out ourselves.

Post by Stephen Howe

Post by Dan Barclay
Hint two: There are several versions of LINK.exe that work with MOVE.
HOWEVER, there is exactly *one* version that works with MOVE in VBDOS.
That is the LINK.EXE that came with VBDOS.

That was not the client's experience.
The last version of 16-bit LINK that comes with 16-bit Microsoft C,
version 1.52c was a definite improvement.
My client found that VBDOS's LINK would fail and the later LINK would
succeed.
That last version of LINK had quite a few bugs fixed, bugs still present
in VBDOS 1.0's LINK.
You can get this version from here
ftp://ftp.microsoft.com/Softlib/MSLFILES/LNK563.EXE
I will lay hands that the tools that come with 1.52c are likely to be at
the most bug free they are ever likely to be.
Microsoft stopped working on 16-bit technology after this.
So NMAKE from this, LIB from this, LINK from this etc will be the best you
can get.

If the 1.52c LINK works for them, that's great. As I said, I did this some
time ago and at that time the later versions of LINK would create invalid
exe's using VBDOS. I don't recall the details, but I did prove the fact
personally<g> and MS confirmed it. I didn't have time to track down what
the problem was. It may have been a simple bug in the later version that
they fixed later. C7 and the next version (as I recall) were problems.

I'm glad to hear that they fixed it right as a "last version". Too bad they
didn't do that with VBDOS!

Post by Stephen Howe
According to the VB documentation, MOVE supported old specification with
linker response file and new specification with a DEF file specifying the
SEGMENTs (like a 16-bit Windows program).
I could not get old new specification to work, the linker would blow up.
In contrast the old system using (, ) and +'s worked no problem.

I used a DEF file exclusively. I had waaayyy to many segments to try doing
it the other way without losing the rest of my mind.

Post by Stephen Howe

Post by Dan Barclay
As you surmised earlier, there is a limit on the overlay size. I don't
remember all the rules <sigh>, but they are fairly easy to live with. As
I recall there is a limit on individual overlay size, in addition to a
limit on total overlay. I seem to recall that it will keep a maximum of
3 overlays in memory at once.

It is not quite that.
The Overlay Area is set to the sum of the size of the 3 largest OBJ's if
possible. Otherwise the largest OBJ.
As many overlays as possible will be in a cache principle basis.

Post by Dan Barclay
The overlay limits could be tinkered with slightly by changing a startup
module (in assembler) and using the alternate .obj file for it.

See Move documentation. You can control things with ENV variables.
I found moveinit inside VBDCL10E.LIB but did not disassemble it to see if
it conformed to the online documentation.

Somewhere I have the source for _moveinit if you need me to track it down
for you.

Post by Stephen Howe

Post by Dan Barclay
You can group .obj's into overlays using a complicated command line
grouping, but the best way is to create an overlay specification file.

If you means a linker response file, that is what the client had.
If you mean a DEF file with SEGMENT definitions (what the VBDOS
documentation recommended: could not get it to work)

The sample I mentioned earlier used this method and it worked fine for me.

Post by Stephen Howe

Post by Dan Barclay
re: xref, I think that program worked on a module level didn't it? I
don't think it would care about overlays or program size.

Nope. With XREF, you fed it a MAK file, which has a complete list of all
the BAS files.
I wanted to use XREF to find unused variables and that means you _must_
feed it everything.
At about 900 modules, it was too big for XREF, even compiled with Far
strings :-(

Are you talking about Crescent's XRef? Maybe I had an earlier version or my
memory is going completely to hell (likely for this stuff). Most of my DOS
stuff was early version<g>.

Post by Stephen Howe
I will try relinking with Watcom's WLINK from 10.6. That supported static
and dynamic overlays and in particular, the MAPs were the best of any
linker. The MAPs revealed unused symbols. It also support CodeView
debugging info. I will see if I can get progress here.

One other thing, in trying to overlay VBDOS apps there are issues overlaying
some of the MS library. If you want a small memory footprint it's best to
avoid sucking in the forms engine at all (MSGBOX will cost you several
hundred k). You probably know that, but for others it might make some
difference. I was unsuccessful in overlaying that code. I found VBDOS
great for DOS apps, so long as you avoided the "V" part.

BTW, if you are doing much FP math work there is a patch that will help
speed significantly. There are also bugs in the optimizer that actually
slowed down some string operations depending on syntax you used.

It's refreshing to see that somebody is actually still having fun with this
stuff. It was great while it lasted for me, but I couldn't give a way a DOS
app in my market even though it would be much faster.

Dan

[Stephen Howe]

Post by Dan Barclay
If the 1.52c LINK works for them, that's great. As I said, I did this some
time ago and at that time the later versions of LINK would create invalid
exe's using VBDOS. I don't recall the details, but I did prove the fact
personally<g> and MS confirmed it. I didn't have time to track down what
the problem was. It may have been a simple bug in the later version that
they fixed later. C7 and the next version (as I recall) were problems.

Very very interesting. Thanks for the info.
It would be good to get a complete version history of LINK between these
points and find out what bug fixes occurred at what point in the timeline.
Considering this is already old technology, the chances of getting that
history seems on the low percentage side (but you never know).

Post by Dan Barclay

Post by Stephen Howe
See Move documentation. You can control things with ENV variables.
I found moveinit inside VBDCL10E.LIB but did not disassemble it to see if
it conformed to the online documentation.

Somewhere I have the source for _moveinit if you need me to track it down
for you.

Thank. I can extract the OBJ from 1.52c and VBDCL10E.LIB, run WDIS on it
(Watcoms disassemble utility) and get perfect assembler listing. From this I
can work out if Microsoft made any changes to it over 2 years from VBDOS 1.0
to Microsoft C 1.52c

Post by Dan Barclay
The sample I mentioned earlier used this method and it worked fine for me.

Interesting. I might retry this at the clients site.

What I noticed was that the MOVE online documentation examples were terms of
functions (and I recognised them as Microsoft C functions) where as the
VBDOS documentation was in terms of SEGMENTs. It was not clear either if you
wanted 2+ modules in one overlay, did you specify the same overlay number at
the end (eg. OVL: 6)? And no examples which showed what you did with root
segments (we left them out). (Also for Microsoft C: If you are going to
start placing different functions from one module in different overlays -
then you surely must compile with the switch that places each function in
its own segment?)

So all-in-all, I concluded the documentation was weak and a bit sparse.
A few more examples would not have gone amiss.
But as I could not get it to work, we kept it in the old link description
format

Post by Dan Barclay
Are you talking about Crescent's XRef?

Yes I am. I have it at home but forgot to take it to the clients site.
XRef, I have found works fine with 7-10 modules, no problem
And I have no idea what its upper limit is in terms of module.
But it clearly barfed at the 900 module program.
Ethan was kind enough to send XRef while I was there.
The client had QuickPak Professional 4.0
So I recompiled XRef with far strings, relinked, no problem
This time XRefFarString went further, but error 9 occured in QMAP.BAS at 3
modules in.
AFAIK, XRef never used EMS or XMS, so these memory limits are not too
surprising.

Post by Dan Barclay

Post by Stephen Howe
I will try relinking with Watcom's WLINK from 10.6. That supported static
and dynamic overlays and in particular, the MAPs were the best of any
linker. The MAPs revealed unused symbols. It also support CodeView
debugging info. I will see if I can get progress here.

One other thing, in trying to overlay VBDOS apps there are issues overlaying
some of the MS library.

All of the MS Libraries were in the root.
But I know what you mean.
Only the clients own code was in overlays.

Post by Dan Barclay
If you want a small memory footprint it's best to
avoid sucking in the forms engine at all (MSGBOX will cost you several
hundred k).

The client is not using any forms from VBDOS at all.
And the MAP file confirms that none of forms stuff is being sucked in from
VBDCL10E.LIB.
So no forms code :)

Post by Dan Barclay
You probably know that, but for others it might make some
difference. I was unsuccessful in overlaying that code. I found VBDOS
great for DOS apps, so long as you avoided the "V" part.

:-)

Post by Dan Barclay
BTW, if you are doing much FP math work there is a patch that will help
speed significantly. There are also bugs in the optimizer that actually
slowed down some string operations depending on syntax you used.

Interesting. I was under the impression that once VBDOS went live, Microsoft
never did one stroke of work subsequently on it. So there were patches to
it?

Stephen Howe

[Dan Barclay]

Post by Stephen Howe

Post by Dan Barclay
BTW, if you are doing much FP math work there is a patch that will help
speed significantly. There are also bugs in the optimizer that actually
slowed down some string operations depending on syntax you used.

Interesting. I was under the impression that once VBDOS went live, Microsoft
never did one stroke of work subsequently on it.

MS did absolutely zip for VBDOS so the latest version is 1.0000000. The
Product Manager *personally* promised me a patch release but, of course, it
never came. (note to self: take a hint)

Post by Stephen Howe
So there were patches to
it?

Heh. I never said it was a MS patch<g>. The FP lib calls are self
modifying. The first time they're called they hit an INT that patches in a
direct call. One of the instructions (I can't remember which now) did not
modify itself so it would continue to hit the INT, which could be a
substantial performance hit especially on virtualized INT's. This would
only affect performance with looped code since first call was still to an
INT. Several of us worked out a patch on the old CI$ forum.

Dang, my memory is getting old just like the rest of me. I'll see if I can
find that. I thought I sent it to somebody who wanted to put it on their
web site but I can't remember where that might be. It doesn't appear to be
on Ethan or Jim's sites.

Dan

[Stephen Howe]

Post by Dan Barclay

Post by Stephen Howe
So there were patches to
it?

Heh. I never said it was a MS patch<g>. The FP lib calls are self
modifying. The first time they're called they hit an INT that patches in a
direct call. One of the instructions (I can't remember which now) did not
modify itself so it would continue to hit the INT, which could be a
substantial performance hit especially on virtualized INT's. This would
only affect performance with looped code since first call was still to an
INT. Several of us worked out a patch on the old CI$ forum.

I know of this system. Compiler vendors used it for 16-bit programs.
Interrupts 39H to 3DH (3EH for Borland) were used for coprocessor
instructions and the interrupt back patched so the call was amended to a F
instruction if the coprocessor was present otherwise a far call if absent.
So, ..., the back patching was not always getting done? Naughty.

For 32-bit programs a INT 7 exception handler was installed that did
something similar.

But on Microsoft library code: It tends to be pretty good but not 100%
perfect.
I remember looking at their graphics code and concluding for SCREEN Mode 2,
that changing the palette for index 1 does not have to be "illegal function
call" for VGA.

Post by Dan Barclay
Dang, my memory is getting old just like the rest of me. I'll see if I can
find that. I thought I sent it to somebody who wanted to put it on their
web site but I can't remember where that might be. It doesn't appear to be
on Ethan or Jim's sites.

The patch I presume? Some skimpy details on the interrupts are in Ralf
Browns Interrupt list.

Stephen Howe

[Dan Barclay]

Post by Stephen Howe

Post by Dan Barclay

Post by Stephen Howe
So there were patches to
it?

Heh. I never said it was a MS patch<g>. The FP lib calls are self
modifying. The first time they're called they hit an INT that patches in

a

Post by Dan Barclay
direct call. One of the instructions (I can't remember which now) did not
modify itself so it would continue to hit the INT, which could be a
substantial performance hit especially on virtualized INT's. This would
only affect performance with looped code since first call was still to an
INT. Several of us worked out a patch on the old CI$ forum.

I know of this system. Compiler vendors used it for 16-bit programs.
Interrupts 39H to 3DH (3EH for Borland) were used for coprocessor
instructions and the interrupt back patched so the call was amended to a F
instruction if the coprocessor was present otherwise a far call if absent.
So, ..., the back patching was not always getting done? Naughty.
For 32-bit programs a INT 7 exception handler was installed that did
something similar.
But on Microsoft library code: It tends to be pretty good but not 100%
perfect.
I remember looking at their graphics code and concluding for SCREEN Mode 2,
that changing the palette for index 1 does not have to be "illegal function
call" for VGA.

Post by Dan Barclay
Dang, my memory is getting old just like the rest of me. I'll see if I

can

Post by Dan Barclay
find that. I thought I sent it to somebody who wanted to put it on their
web site but I can't remember where that might be. It doesn't appear to

be

Post by Dan Barclay
on Ethan or Jim's sites.

The patch I presume? Some skimpy details on the interrupts are in Ralf
Browns Interrupt list.

Yes, the patch.

It's in a 4k zip file with source and .obj file. The source has a complete
explanation of what it's doing. It was based on work provided by a guy
named Jonathan Sawyer and I just added attribution in the asm file for that
and re-zipped it. Jonathan indicated that it also worked for PDS and QB4.5,
but I haven't tested it with those. It provides a 3x to 4x speed increase
in a lot of cases.

I'll be glad to forward it if you need it.

Dan

[Stephen Howe]

Post by Dan Barclay
I'll be glad to forward it if you need it.

Thanks yes please.
My work email is in the headers but it needs demangling but it should be
obvious.

Stephen Howe

[Dan Barclay]

Done.

Post by Stephen Howe

Post by Dan Barclay
I'll be glad to forward it if you need it.

Thanks yes please.
My work email is in the headers but it needs demangling but it should be
obvious.
Stephen Howe

[Dan Barclay]

Stephen,

A couple of questions...

Did the overlay example help resolve any questions you had on that? In
particular, were you able to get the DEF files to work for you?

If not, maybe that was the problem with the later link.exe's. Give the
VBDOS one a shot. The version number is listed in the readme file.

Also let me know if the math patch helped you. It's really effective in
tightly looped or iterative code.

Dan

Post by Dan Barclay

Post by Stephen Howe

Post by Dan Barclay

Post by Stephen Howe
So there were patches to
it?

Heh. I never said it was a MS patch<g>. The FP lib calls are self
modifying. The first time they're called they hit an INT that patches in

a

Post by Dan Barclay
direct call. One of the instructions (I can't remember which now) did not
modify itself so it would continue to hit the INT, which could be a
substantial performance hit especially on virtualized INT's. This would
only affect performance with looped code since first call was still to an
INT. Several of us worked out a patch on the old CI$ forum.

I know of this system. Compiler vendors used it for 16-bit programs.
Interrupts 39H to 3DH (3EH for Borland) were used for coprocessor
instructions and the interrupt back patched so the call was amended to a F
instruction if the coprocessor was present otherwise a far call if absent.
So, ..., the back patching was not always getting done? Naughty.
For 32-bit programs a INT 7 exception handler was installed that did
something similar.
But on Microsoft library code: It tends to be pretty good but not 100%
perfect.
I remember looking at their graphics code and concluding for SCREEN Mode 2,
that changing the palette for index 1 does not have to be "illegal function
call" for VGA.

Post by Dan Barclay
Dang, my memory is getting old just like the rest of me. I'll see if I

can

Post by Dan Barclay
find that. I thought I sent it to somebody who wanted to put it on their
web site but I can't remember where that might be. It doesn't appear to

be

Post by Dan Barclay
on Ethan or Jim's sites.

The patch I presume? Some skimpy details on the interrupts are in Ralf
Browns Interrupt list.

Yes, the patch.
It's in a 4k zip file with source and .obj file. The source has a
complete explanation of what it's doing. It was based on work provided by
a guy named Jonathan Sawyer and I just added attribution in the asm file
for that and re-zipped it. Jonathan indicated that it also worked for PDS
and QB4.5, but I haven't tested it with those. It provides a 3x to 4x
speed increase in a lot of cases.
I'll be glad to forward it if you need it.
Dan

[Stephen Howe]

Post by Dan Barclay
A couple of questions...

Sorry for the delay in replying...
And thanks for the files

Post by Dan Barclay
Did the overlay example help resolve any questions you had on that? In
particular, were you able to get the DEF files to work for you?

Well the customer is using the old method (no DEFs) and not the new method
(with DEFs).
I am no longer there. Back in London, no longer in Bristol.
But I mean to go through the example you sent and try it myself.
The customer is trying

Post by Dan Barclay
If not, maybe that was the problem with the later link.exe's. Give the
VBDOS one a shot. The version number is listed in the readme file.

I will try both linkers and report what I find.
I also want to try Watcom's WLINK from 10.6 as that supports overlays and I
want to see what MAP output I get.

Post by Dan Barclay
Also let me know if the math patch helped you. It's really effective in
tightly looped or iterative code.

I found it very interesting. Thanks.
It is not quite a patch replacement for Microsofts own code is it?

Thanks

Stephen Howe

[Dan Barclay]

Post by Stephen Howe

Post by Dan Barclay
A couple of questions...

Sorry for the delay in replying...
And thanks for the files

Post by Dan Barclay
Did the overlay example help resolve any questions you had on that? In
particular, were you able to get the DEF files to work for you?

Well the customer is using the old method (no DEFs) and not the new method
(with DEFs).
I am no longer there. Back in London, no longer in Bristol.
But I mean to go through the example you sent and try it myself.
The customer is trying

Post by Dan Barclay
If not, maybe that was the problem with the later link.exe's. Give the
VBDOS one a shot. The version number is listed in the readme file.

I will try both linkers and report what I find.
I also want to try Watcom's WLINK from 10.6 as that supports overlays and
I want to see what MAP output I get.

Post by Dan Barclay
Also let me know if the math patch helped you. It's really effective in
tightly looped or iterative code.

I found it very interesting. Thanks.
It is not quite a patch replacement for Microsofts own code is it?

Well, I suppose you'd call it a "realtime patch" <vbg>. The replacement ISR
patches the MS code at runtime<g>.

FWIW, the end result of executable code is identical to (correct) code in
the C libs of that line. The tricks they wouldn't try to keep Basic from
being faster than C <lol>.

Dan

[Dan Barclay]

Post by Stephen Howe
Thank. I can extract the OBJ from 1.52c and VBDCL10E.LIB, run WDIS on it
(Watcoms disassemble utility) and get perfect assembler listing. From this I
can work out if Microsoft made any changes to it over 2 years from VBDOS 1.0
to Microsoft C 1.52c

Post by Dan Barclay
The sample I mentioned earlier used this method and it worked fine for me.

Interesting. I might retry this at the clients site.
What I noticed was that the MOVE online documentation examples were terms of
functions (and I recognised them as Microsoft C functions) where as the
VBDOS documentation was in terms of SEGMENTs. It was not clear either if you
wanted 2+ modules in one overlay, did you specify the same overlay number at
the end (eg. OVL: 6)? And no examples which showed what you did with root
segments (we left them out). (Also for Microsoft C: If you are going to
start placing different functions from one module in different overlays -
then you surely must compile with the switch that places each function in
its own segment?)
So all-in-all, I concluded the documentation was weak and a bit sparse.
A few more examples would not have gone amiss.
But as I could not get it to work, we kept it in the old link description
format

Yes, you specify overlays by module name and assign the same number for ones
you want grouped.

I found the sample micro-project I mentioned earlier. Its about a 4k zip as
a complete project including batch files for execution. Here's the Read.Me
from it. If you want the zip, post your actual email address (mangle it a
bit first) and I'll email it.

Dan

============================

OVRLAY.ZIP
Creating MOVE overlays with VBDOS


This set of programs demonstrates the use ofOverlays in VBDOS.

The simple project consists of a Main program contained in
the file (surprise!) MAINPGM.BAS and four subroutines (Phred, Tom,
Dick and Harry) contained in the files:

MOD1.BAS (Phred and Tom)
MOD2.BAS (Dick)
MOD3.BAS (Harry)

Overlays will be structured so that Phred and Tom are in Overlay 1
and Dick and Harry are in Overlay 2.

The DEF file to accomplish this looks like:

SEGMENTS
'MOD1_CODE' CLASS 'BC_CODE' OVL:1
'MOD2_CODE' CLASS 'BC_CODE' OVL:2
'MOD3_CODE' CLASS 'BC_CODE' OVL:2


Note that "_CODE" is appended to the module (file) name
and that the CLASS is "BC_CODE". Overlays are assigned by
module.


The OVLPGM.MAP file shows the overlays created (see the bottom of
the MAP listing). If your MAP file does not show the Overlays, then
you haven't created any.

Important tips:

Use the LINKer supplied with VBDOS when overlaying VBDOS
programs (ver 5.31.009).

You cannot use CHAIN with overlays.

If you are using "RUN ProgramName$" with overlaid programs
you must manually close the overlay files. Use the
CloseOverlayPause routine in OVLRUN.ZIP.

Use either the DEF file method or the command line () method
of specifying overlay structure *but not both*. The DEF file
method is recommended.

Although the modules here were specified on the command line,
MODn files could just have easily been from a LIB file if the
DEF file method is used to specify structure.


===========
Dan Barclay
===========

Files in this Zip:

MAINDEF DEF 124 08-31-93 4:12p DEF file for overlay linker
MAINPGM BAS 1180 08-31-93 4:12p MAIN Basic program
MKPGM BAT 110 08-31-93 4:14p Batch file to create overlaid EXE
MOD1 BAS 221 08-31-93 4:05p Module 1 Basic file
MOD2 BAS 139 08-31-93 4:05p Module 2 Basic file
MOD3 BAS 145 08-31-93 4:05p Module 3 Basic file
OVLPGM MAP 4317 08-31-93 4:15p Example MAP of overlaid EXE
READ ME 725 08-31-93 4:16p This file