VBDOS + Overlays

news.microsoft.com · Joined: 04 Oct 2007 Posts: 11

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

Archived from group: microsoft>public>vb>dos

Ethan Winer · Joined: 04 Oct 2007 Posts: 30

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 · Joined: 04 Oct 2007 Posts: 11

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%.

> 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 Sad

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 Sad

. Not used it in 14 years.

> 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

news.microsoft.com · Joined: 04 Oct 2007 Posts: 11

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 · Joined: 04 Oct 2007 Posts: 11

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

ararghmail510NOSPAM · Joined: 04 Oct 2007 Posts: 10

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

>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?

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

Which is a good idea in any event. Smile

--
ArarghMail510 at [drop the 'http://www.' from ->] http://www.arargh.com
BCET Basic Compiler Page: http://www.arargh.com/basic/index.html

To reply by email, remove the garbage from the reply address.

ararghmail510NOSPAM · Joined: 04 Oct 2007 Posts: 10

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

>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?

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

--
ArarghMail510 at [drop the 'http://www.' from ->] http://www.arargh.com
BCET Basic Compiler Page: http://www.arargh.com/basic/index.html

To reply by email, remove the garbage from the reply address.

news.microsoft.com · Joined: 04 Oct 2007 Posts: 11

> Try linking with "NOISAM.OBJ" - stubs out ISAM code.
>
> Which is a good idea in any event. Smile

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

Ethan Winer · Joined: 04 Oct 2007 Posts: 30

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 · Joined: 04 Oct 2007 Posts: 11

> 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.

> > 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

news.microsoft.com · Joined: 04 Oct 2007 Posts: 11

> 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 Sad

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

Stephen Howe

news.microsoft.com · Joined: 04 Oct 2007 Posts: 11

> > 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

ararghmail510NOSPAM · Joined: 04 Oct 2007 Posts: 10

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

>> > 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
--
ArarghMail510 at [drop the 'http://www.' from ->] http://www.arargh.com
BCET Basic Compiler Page: http://www.arargh.com/basic/index.html

To reply by email, remove the garbage from the reply address.

news.microsoft.com · Joined: 04 Oct 2007 Posts: 11

> 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 · Joined: 04 Oct 2007 Posts: 30

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

making apps in vbdos then loading them within vbdos HI, I have a simple app, but my friend wants to help as well, rather than giving whole source, Im thinking that if he has vbdos aswell, then he could make his app(basic text view'r) with a FD.exe, so then its like another app but on its own form/window, i

VBDOS under XP I've been trying to run VBDOS under Windows XP, but there appears to be alot of strange errors and crashes, does anybody know if this is an XP problem or just specific to my setup? Is there any way to correct it? I'm sure VBDOS runs OK under NT 4.0 and I

VBDOS Tutorials Hi, i'm looking for tutorials on VBDOS. Does anyone know where to go to find free tutorials? -J. Christensen

VBDOS 1.0 terminates itself VBDOS 1.0 terminates itself. If it's because the ".mak" file has too many forms and modules, how do I fix this? I am using VBDOS in Windows XP Pro Edition. Thanks in advance

Copy of VBDOS Hello. I am desperatly trying to get hold of VB FOR DOS and can't see anywhere I can buy it on the net. I am prepared to pay a substantial amount from anywhere... Shipping to the UK would be required. Any help would be apreciated. Thank you Daz Elleringto