[budgie]

Yes, unfortunately I'm back ...

This olde QB45 app is now 3/4's converted to VBDOS, and runs fine in the IDE.
But when I attempt compilation, it faults. If I try in the DOS box (under 98SE)
it exits with a Windows error message "tried to execute an invalid instruction".
If I boot to command prompt and run VBDOS from there, it just locks up while
presumably still in BC.EXE. In each case I am attempting to compile from with
the IDE, not command line.

Thinking it may be caused by corruption, I reinstalled VBDOS from scratch - same
result. To test if it was something about this platform (P3-666 Win98SE), I
built another app about half the size, and it compiled and ran fine. That of
course is not conclusive.

Before resorting to troubling the resident gurus here, I also tried stripping
down the app to two forms and removing about 80% of the SUBs and REMing their
calls, in case there was a tainted module or SUB. Removed all file access
references. Still no go.

This is a simple app, no interrupt calls or anything fancy.

Is there an issue with compiling VBDOS in a P3 (or any other specific platform)?

Is there any other known comp issues I need to be aware of?

All help appreciated. What I hoped would be a short exercise has started to
haunt me.

Archived from group: microsoft>public>vb>dos

[Dan Barclay]

Man, it's been way too long since I fooled with this so I can't give you a
complete answer. I can give you some direction to try though.

Execute BC from the command line with /? to get a list of command line
switches. One of those switches will affect how memory is used (I remember
something like /R but I don't trust that memory).

Also check the exit status when you do get a compile for free space etc. In
the environment you're running in a pcode interpreter. BC compiles to
native. There's a difference in how big a module they can handle and your
module may simply be too big for BC. You can create very large exe's with
VBDOS but individual modules have limits. Technically the limit is 64k of
executable code, but you'll hit internal compiler memory limits first.

If you're hitting those limits, the solution is to break the larger modules
into more modules.

Dan


"budgie" wrote in message @4ax.com...
> Yes, unfortunately I'm back ...
>
> This olde QB45 app is now 3/4's converted to VBDOS, and runs fine in the
> IDE.
> But when I attempt compilation, it faults. If I try in the DOS box (under
> 98SE)
> it exits with a Windows error message "tried to execute an invalid
> instruction".
> If I boot to command prompt and run VBDOS from there, it just locks up
> while
> presumably still in BC.EXE. In each case I am attempting to compile from
> with
> the IDE, not command line.
>
> Thinking it may be caused by corruption, I reinstalled VBDOS from
> scratch - same
> result. To test if it was something about this platform (P3-666 Win98SE),
> I
> built another app about half the size, and it compiled and ran fine. That
> of
> course is not conclusive.
>
> Before resorting to troubling the resident gurus here, I also tried
> stripping
> down the app to two forms and removing about 80% of the SUBs and REMing
> their
> calls, in case there was a tainted module or SUB. Removed all file access
> references. Still no go.
>
> This is a simple app, no interrupt calls or anything fancy.
>
> Is there an issue with compiling VBDOS in a P3 (or any other specific
> platform)?
>
> Is there any other known comp issues I need to be aware of?
>
> All help appreciated. What I hoped would be a short exercise has started
> to
> haunt me.

[budgie]

On Sun, 12 Mar 2006 02:10:20 -0600, "Dan Barclay" wrote:

>Man, it's been way too long since I fooled with this so I can't give you a
>complete answer. I can give you some direction to try though.
>
>Execute BC from the command line with /? to get a list of command line
>switches. One of those switches will affect how memory is used (I remember
>something like /R but I don't trust that memory).
>
>Also check the exit status when you do get a compile for free space etc. In
>the environment you're running in a pcode interpreter. BC compiles to
>native. There's a difference in how big a module they can handle and your
>module may simply be too big for BC. You can create very large exe's with
>VBDOS but individual modules have limits. Technically the limit is 64k of
>executable code, but you'll hit internal compiler memory limits first.
>
>If you're hitting those limits, the solution is to break the larger modules
>into more modules.

Thanks for the pointers. I'm not getting any exit codes of course compiling
from the IDE - just a solid machine lockup from DOS(7) or a Win error from the
DOS box.

I can see the command line that the IDE generates when starting from DOS, so
that'll be something to consider vis-a-vis the /? listing.

I don't think any of the modules would exceed 64k compiled - the largest .FRM is
only 9k, the biggest .BAS module is 8k (and half that is comments!).

Peter

[ArarghMail603NOSPAM]

On Sun, 12 Mar 2006 14:06:40 +0800, budgie wrote:

>Yes, unfortunately I'm back ...
>
>This olde QB45 app is now 3/4's converted to VBDOS, and runs fine in the IDE.
>But when I attempt compilation, it faults. If I try in the DOS box (under 98SE)
>it exits with a Windows error message "tried to execute an invalid instruction".
>If I boot to command prompt and run VBDOS from there, it just locks up while
>presumably still in BC.EXE. In each case I am attempting to compile from with
>the IDE, not command line.

Probably a memory size issue. That error message is the one I get in
the PDS IDE when I try to use too much memory (either string or
redimmed arrays)

Try compiling it from the command line. It that fails, time to split
the program into seceral source files. BTDT.

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

[Bob O`Bob]

ArarghMail603NOSPAM@NOT.AT.Arargh.com wrote:
> On Sun, 12 Mar 2006 14:06:40 +0800, budgie wrote:
>
>> Yes, unfortunately I'm back ...
>>
>> This olde QB45 app is now 3/4's converted to VBDOS, and runs fine in the IDE.
>> But when I attempt compilation, it faults. If I try in the DOS box (under 98SE)
>> it exits with a Windows error message "tried to execute an invalid instruction".
>> If I boot to command prompt and run VBDOS from there, it just locks up while
>> presumably still in BC.EXE. In each case I am attempting to compile from with
>> the IDE, not command line.
>
> Probably a memory size issue. That error message is the one I get in
> the PDS IDE when I try to use too much memory (either string or
> redimmed arrays)
>
> Try compiling it from the command line. It that fails, time to split
> the program into seceral source files. BTDT.
>


I hope he has the "Pro" version of VBDOS ... he may end up needing the overlay linker.



Bob

[ArarghMail603NOSPAM]

On Sun, 12 Mar 2006 12:02:39 -0800, Bob O`Bob
wrote:

>ArarghMail603NOSPAM@NOT.AT.Arargh.com wrote:
>> On Sun, 12 Mar 2006 14:06:40 +0800, budgie wrote:
>>
>>> Yes, unfortunately I'm back ...
>>>
>>> This olde QB45 app is now 3/4's converted to VBDOS, and runs fine in the IDE.
>>> But when I attempt compilation, it faults. If I try in the DOS box (under 98SE)
>>> it exits with a Windows error message "tried to execute an invalid instruction".
>>> If I boot to command prompt and run VBDOS from there, it just locks up while
>>> presumably still in BC.EXE. In each case I am attempting to compile from with
>>> the IDE, not command line.
>>
>> Probably a memory size issue. That error message is the one I get in
>> the PDS IDE when I try to use too much memory (either string or
>> redimmed arrays)
>>
>> Try compiling it from the command line. It that fails, time to split
>> the program into seceral source files. BTDT.
>>
>
>I hope he has the "Pro" version of VBDOS ... he may end up needing the overlay linker.

That depends upon the runtime memory requirements. I have several
projects that only just barely run in the IDE, and can no way be
compiled as a single source file, which runs 250+k. Because of the
large number include files, I can't have multiple source files in the
IDE -- it won't even finish loading. So, I develop as a single large
source file, and use a custom program to split it up into multiple
sources to compile, and then link the whole mess together. The EXEs
run about 400k. It's somewhat of a kludge, but it works.

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

[budgie]

Comments in-line ...

On Sun, 12 Mar 2006 15:26:22 -0600, ArarghMail603NOSPAM@NOT.AT.Arargh.com wrote:

>On Sun, 12 Mar 2006 12:02:39 -0800, Bob O`Bob
> wrote:
>
>>ArarghMail603NOSPAM@NOT.AT.Arargh.com wrote:
>>> On Sun, 12 Mar 2006 14:06:40 +0800, budgie wrote:
>>>
>>>> Yes, unfortunately I'm back ...
>>>>
>>>> This olde QB45 app is now 3/4's converted to VBDOS, and runs fine in the IDE.
>>>> But when I attempt compilation, it faults. If I try in the DOS box (under 98SE)
>>>> it exits with a Windows error message "tried to execute an invalid instruction".
>>>> If I boot to command prompt and run VBDOS from there, it just locks up while
>>>> presumably still in BC.EXE. In each case I am attempting to compile from with
>>>> the IDE, not command line.
>>>
>>> Probably a memory size issue. That error message is the one I get in
>>> the PDS IDE when I try to use too much memory (either string or
>>> redimmed arrays)

There are precious few strings used - short "help"s and prompts in MSGBOXes etc,
and filenames for I/O is about it.

One array - integer x2K and not REDIMmed (well, not knowingly).

>>> Try compiling it from the command line. It that fails, time to split
>>> the program into seceral source files. BTDT.

The actual command line used from the IDE is /E/X/O/T/C:512. The only thing I
would have done differently is omit the T. The C: is academic as there is no
use of COM ports.

But I will try.

Question: From the IDE the internal call to BC presumably compiles each module
and invokes the linker to link all the .OBJ files and required system bits into
the resultant .EXE. From the command line I don't seem to have the facility to
do other than compile one module at a time.

>>I hope he has the "Pro" version of VBDOS ... he may end up needing the overlay linker.

Unfortunately no.

As I mentioned in my reply to Dan, the largest module is <10k and there are
currently five modules plus a small $INCLUDE file housing COMMOM SHARED
definitions. One integer array size 2K elements. Nothing that i would have
anticipated would challenge VBDOS.

>That depends upon the runtime memory requirements. I have several
>projects that only just barely run in the IDE, and can no way be
>compiled as a single source file, which runs 250+k. Because of the
>large number include files, I can't have multiple source files in the
>IDE -- it won't even finish loading. So, I develop as a single large
>source file, and use a custom program to split it up into multiple
>sources to compile, and then link the whole mess together. The EXEs
>run about 400k. It's somewhat of a kludge, but it works.

[ArarghMail603NOSPAM]

On Mon, 13 Mar 2006 07:18:17 +0800, budgie wrote:

>Comments in-line ...
>
>On Sun, 12 Mar 2006 15:26:22 -0600, ArarghMail603NOSPAM@NOT.AT.Arargh.com wrote:
>
>>On Sun, 12 Mar 2006 12:02:39 -0800, Bob O`Bob
>> wrote:
>>
>>>ArarghMail603NOSPAM@NOT.AT.Arargh.com wrote:
>>>> On Sun, 12 Mar 2006 14:06:40 +0800, budgie wrote:
>>>>
>>>>> Yes, unfortunately I'm back ...
>>>>>
>>>>> This olde QB45 app is now 3/4's converted to VBDOS, and runs fine in the IDE.
>>>>> But when I attempt compilation, it faults. If I try in the DOS box (under 98SE)
>>>>> it exits with a Windows error message "tried to execute an invalid instruction".
>>>>> If I boot to command prompt and run VBDOS from there, it just locks up while
>>>>> presumably still in BC.EXE. In each case I am attempting to compile from with
>>>>> the IDE, not command line.
>>>>
>>>> Probably a memory size issue. That error message is the one I get in
>>>> the PDS IDE when I try to use too much memory (either string or
>>>> redimmed arrays)
>
>There are precious few strings used - short "help"s and prompts in MSGBOXes etc,
>and filenames for I/O is about it.
>
>One array - integer x2K and not REDIMmed (well, not knowingly).
>
>>>> Try compiling it from the command line. It that fails, time to split
>>>> the program into several source files. BTDT.
>
>The actual command line used from the IDE is /E/X/O/T/C:512. The only thing I
>would have done differently is omit the T.

/T shouldn't make much difference.


>The C: is academic as there is no use of COM ports.

Makes no difference. All these 'NO'something files wouldn't exist for
no reason. You get library support for everything, unless you include
the correct 'NO' file. At least that's the way it worked in PDS, and
I can't see MS having changed things.

NOCGA .OBJ 137 08-19-92 5:59p
NOCOM .OBJ 502 08-19-92 5:59p
NOEDIT .OBJ 551 08-19-92 5:59p
NOEGA .OBJ 164 08-19-92 5:59p
NOEVENT .OBJ 533 08-19-92 5:59p
NOFLTIN .OBJ 457 08-19-92 5:59p
NOFORMS .OBJ 1,182 08-19-92 5:59p
NOGRAPH .OBJ 700 08-19-92 5:59p
NOHERC .OBJ 125 08-19-92 5:59p
NOISAM .OBJ 331 08-19-92 5:59p
NOLPT .OBJ 216 08-19-92 5:59p
NOOGA .OBJ 124 08-19-92 5:59p
NOTRNEM .LIB 14,879 08-19-92 5:59p
NOVGA .OBJ 168 08-19-92 5:59p

>
>But I will try.
>
>Question: From the IDE the internal call to BC presumably compiles each module
>and invokes the linker to link all the .OBJ files and required system bits into
>the resultant .EXE. From the command line I don't seem to have the facility to
>do other than compile one module at a time.

You would have to create a make file to do it for you. And looking, I
see that MS didn't bother to supply MAKE with VBDOS. Well, you could
always create a batch file.

Something like:

BC ,,;
BC ,,;
BC ,,;

LINK ,,,;


More than likely that will wind up being too long (>127 chars), and
wou will have to resort to the reponse file option.

LINK @ (where the responce file can be just one line
that looks like the command line. IIRC)


I am not sure which libs that would be needed, probably VBDRT10E.LIB
at a minimum.




I always use one of these two methods. I don't think that I have EVER
used the IDE to compile anything.

>
>>>I hope he has the "Pro" version of VBDOS ... he may end up needing the overlay linker.
>
>Unfortunately no.
>
>As I mentioned in my reply to Dan, the largest module is <10k and there are
>currently five modules plus a small $INCLUDE file housing COMMOM SHARED
>definitions. One integer array size 2K elements. Nothing that i would have
>anticipated would challenge VBDOS.

No, it doesn't sound like it.


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

[budgie]

On Sun, 12 Mar 2006 20:17:04 -0600, ArarghMail603NOSPAM@NOT.AT.Arargh.com wrote:

>On Mon, 13 Mar 2006 07:18:17 +0800, budgie wrote:
>
>>Comments in-line ...
>>
>>On Sun, 12 Mar 2006 15:26:22 -0600, ArarghMail603NOSPAM@NOT.AT.Arargh.com wrote:
>>
>>>On Sun, 12 Mar 2006 12:02:39 -0800, Bob O`Bob
>>> wrote:
>>>
>>>>ArarghMail603NOSPAM@NOT.AT.Arargh.com wrote:
>>>>> On Sun, 12 Mar 2006 14:06:40 +0800, budgie wrote:
>>>>>
>>>>>> Yes, unfortunately I'm back ...
>>>>>>
>>>>>> This olde QB45 app is now 3/4's converted to VBDOS, and runs fine in the IDE.
>>>>>> But when I attempt compilation, it faults. If I try in the DOS box (under 98SE)
>>>>>> it exits with a Windows error message "tried to execute an invalid instruction".
>>>>>> If I boot to command prompt and run VBDOS from there, it just locks up while
>>>>>> presumably still in BC.EXE. In each case I am attempting to compile from with
>>>>>> the IDE, not command line.
>>>>>
>>>>> Probably a memory size issue. That error message is the one I get in
>>>>> the PDS IDE when I try to use too much memory (either string or
>>>>> redimmed arrays)
>>
>>There are precious few strings used - short "help"s and prompts in MSGBOXes etc,
>>and filenames for I/O is about it.
>>
>>One array - integer x2K and not REDIMmed (well, not knowingly).
>>
>>>>> Try compiling it from the command line. It that fails, time to split
>>>>> the program into several source files. BTDT.
>>
>>The actual command line used from the IDE is /E/X/O/T/C:512. The only thing I
>>would have done differently is omit the T.
>
>/T shouldn't make much difference.
>
>
>>The C: is academic as there is no use of COM ports.
>
>Makes no difference. All these 'NO'something files wouldn't exist for
>no reason. You get library support for everything, unless you include
>the correct 'NO' file. At least that's the way it worked in PDS, and
>I can't see MS having changed things.
>
>NOCGA .OBJ 137 08-19-92 5:59p
>NOCOM .OBJ 502 08-19-92 5:59p
>NOEDIT .OBJ 551 08-19-92 5:59p
>NOEGA .OBJ 164 08-19-92 5:59p
>NOEVENT .OBJ 533 08-19-92 5:59p
>NOFLTIN .OBJ 457 08-19-92 5:59p
>NOFORMS .OBJ 1,182 08-19-92 5:59p
>NOGRAPH .OBJ 700 08-19-92 5:59p
>NOHERC .OBJ 125 08-19-92 5:59p
>NOISAM .OBJ 331 08-19-92 5:59p
>NOLPT .OBJ 216 08-19-92 5:59p
>NOOGA .OBJ 124 08-19-92 5:59p
>NOTRNEM .LIB 14,879 08-19-92 5:59p
>NOVGA .OBJ 168 08-19-92 5:59p


I meant C academic in the sense that specifiying a buffer size is academic

>>But I will try.
>>
>>Question: From the IDE the internal call to BC presumably compiles each module
>>and invokes the linker to link all the .OBJ files and required system bits into
>>the resultant .EXE. From the command line I don't seem to have the facility to
>>do other than compile one module at a time.
>
>You would have to create a make file to do it for you. And looking, I
>see that MS didn't bother to supply MAKE with VBDOS. Well, you could
>always create a batch file.

The amount of work makes the "compile from IDE" approach seem so much easier.
But certainly it is another avenue.

>>As I mentioned in my reply to Dan, the largest module is <10k and there are
>>currently five modules plus a small $INCLUDE file housing COMMOM SHARED
>>definitions. One integer array size 2K elements. Nothing that i would have
>>anticipated would challenge VBDOS.
>
>No, it doesn't sound like it.

Re MAKE:

Running BC from the command line without arguments causes it to prompt for a
..FRM or .BAS source file. Instead I fed it the name of the .MAK file to see
what explodes. It duly offered name.OBJ as the output file, then proceeded to
report errors as follows:

Source listing [nul.lst]:

0030 0006 PSTART.FRM
^ Equal sign missing
0030 0006 etc for the remaining modules.
-and-
0 Warning error(s)
6 Severe error(s)

Any idea what it is on about? Is this just BC choking on a .MAK as as
undecipherable format, thinking the module names are LHS of expressions?

[ArarghMail603NOSPAM]

On Mon, 13 Mar 2006 14:28:53 +0800, budgie wrote:


>I meant C academic in the sense that specifiying a buffer size is academic
Yes, but the library code is still there.


>Re MAKE:
>
>Running BC from the command line without arguments causes it to prompt for a
>.FRM or .BAS source file. Instead I fed it the name of the .MAK file to see
>what explodes. It duly offered name.OBJ as the output file, then proceeded to
>report errors as follows:
>
>Source listing [nul.lst]:
>
>0030 0006 PSTART.FRM
> ^ Equal sign missing
>0030 0006 etc for the remaining modules.
>-and-
> 0 Warning error(s)
> 6 Severe error(s)
>
>Any idea what it is on about? Is this just BC choking on a .MAK as as
>undecipherable format, thinking the module names are LHS of expressions?

BC doesn't know anything about .MAK files. Also, the VBDOS .MAK file
format is not compatible with a real make file. And, make doesn't
come with VBDOS -- even the Pro version.

A REAL makefile looks more like:

(begin makefile)
# makefile generated on 09-21-1996 @ 03:06:20 by GenMake
# command$="BC71N [nam]"

LFLG=/map /info /co
BFLG=/o /Zi

..bas.obj:
bc.exe $(BFLG) $(*B).bas, $(*B).obj, $(*B).lst;

all:[nam].exe

[nam].exe:[nam].obj
link $(LFLG) $** ,[nam], [nam], @y:\libs\jlib71nr.rf; >[nam].lnk
(end makefile)

Where [nam] is your source file name, and are real tab chars.
(some versions of make actually care about that)

This sample is incomplete, and is for a single source file, but will
give you the idea.


GenMake is a program I wrote, a long time ago -- looks like sometime
in 1996. It is way too specific to the way I do things, and so would
not be too useful to anyone else.

Just did some checking - it seems that nmake ver 1.11 came with PDS
7.10 - I wonder why it was dropped from VBDOS.



Anyway, if you want, zip up all of your source, .mak and include
files, and email to my (unscrambled) email address, I will write up
the necessary batch file, and see if it works. Except for compiling
it, I probably wouldn't even bother to look at the files (except to
fix errors, if any).

arargh


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

[Stephen Howe]

> This olde QB45 app is now 3/4's converted to VBDOS, and runs fine in the
IDE.
> But when I attempt compilation, it faults. If I try in the DOS box (under
98SE)
> it exits with a Windows error message "tried to execute an invalid
instruction".
> If I boot to command prompt and run VBDOS from there, it just locks up
while
> presumably still in BC.EXE. In each case I am attempting to compile from
with
> the IDE, not command line.
>
> Thinking it may be caused by corruption, I reinstalled VBDOS from
scratch - same
> result. To test if it was something about this platform (P3-666 Win98SE),
I
> built another app about half the size, and it compiled and ran fine. That
of
> course is not conclusive.

I think what you ned to do is provide VBDOS a PIF or alter _DEFAULT.PIF.
What you want to do is provide it as much EMS and XMS memory as possible.
That might enable VBDOS to run.

Stephen Howe

[budgie]

On Mon, 13 Mar 2006 12:32:08 -0000, "Stephen Howe"
wrote:

>> This olde QB45 app is now 3/4's converted to VBDOS, and runs fine in the
>IDE.
>> But when I attempt compilation, it faults. If I try in the DOS box (under
>98SE)
>> it exits with a Windows error message "tried to execute an invalid
>instruction".
>> If I boot to command prompt and run VBDOS from there, it just locks up
>while
>> presumably still in BC.EXE. In each case I am attempting to compile from
>with
>> the IDE, not command line.
>>
>> Thinking it may be caused by corruption, I reinstalled VBDOS from
>scratch - same
>> result. To test if it was something about this platform (P3-666 Win98SE),
>I
>> built another app about half the size, and it compiled and ran fine. That
>of
>> course is not conclusive.
>
>I think what you ned to do is provide VBDOS a PIF or alter _DEFAULT.PIF.
>What you want to do is provide it as much EMS and XMS memory as possible.

Both are currently set to "AUTO" in the Properties->Memory tab

>That might enable VBDOS to run.

[Stephen Howe]

> Running BC from the command line without arguments causes it to prompt for
a
> .FRM or .BAS source file. Instead I fed it the name of the .MAK file to
see
> what explodes.

It won't work. It knows nothing about MAK files. It is looking at MAK file
as if it was a BASIC source file.

> Any idea what it is on about? Is this just BC choking on a .MAK as as
> undecipherable format, thinking the module names are LHS of expressions?

Yup, exactly that.

Stephen Howe

[budgie]

On Mon, 13 Mar 2006 01:47:54 -0600, ArarghMail603NOSPAM@NOT.AT.Arargh.com wrote:

>On Mon, 13 Mar 2006 14:28:53 +0800, budgie wrote:
>
>
>>I meant C academic in the sense that specifiying a buffer size is academic
>Yes, but the library code is still there.
>
>
>>Re MAKE:
>>
>>Running BC from the command line without arguments causes it to prompt for a
>>.FRM or .BAS source file. Instead I fed it the name of the .MAK file to see
>>what explodes. It duly offered name.OBJ as the output file, then proceeded to
>>report errors as follows:
>>
>>Source listing [nul.lst]:
>>
>>0030 0006 PSTART.FRM
>> ^ Equal sign missing
>>0030 0006 etc for the remaining modules.
>>-and-
>> 0 Warning error(s)
>> 6 Severe error(s)
>>
>>Any idea what it is on about? Is this just BC choking on a .MAK as as
>>undecipherable format, thinking the module names are LHS of expressions?
>
>BC doesn't know anything about .MAK files.

I fully expected that, but figured i couldn't break it by trying

(snip)

>Anyway, if you want, zip up all of your source, .mak and include
>files, and email to my (unscrambled) email address, I will write up
>the necessary batch file, and see if it works. Except for compiling
>it, I probably wouldn't even bother to look at the files (except to
>fix errors, if any).

Tnx for the offer - winging its way as I type this. Don't look to closely.

Tnx and good luck making sense of it.

[Dan Barclay]

While VBDOS didn't come with a MAKE file, the MAKE file from any C compiler
will work. If you have VS you'll have a copy of it. You can also find free
MAKE's (open source) around.

VBDOS should have come with MAKE and LIB (I don't remember if it came with
LIB or not). When our app outgrew the IDE we set up a complete build for
out DOS apps, used Brief for an editor, and quit using the IDE completely.
The MOVE overlay manager with VBDOS Pro is great as well, though you'll have
to go find an old C compiler to get decent docs for it.

Dan


"budgie" wrote in message @4ax.com...
> On Mon, 13 Mar 2006 01:47:54 -0600, ArarghMail603NOSPAM@NOT.AT.Arargh.com
> wrote:
>
>>On Mon, 13 Mar 2006 14:28:53 +0800, budgie wrote:
>>
>>
>>>I meant C academic in the sense that specifiying a buffer size is
>>>academic
>>Yes, but the library code is still there.
>>
>>
>>>Re MAKE:
>>>
>>>Running BC from the command line without arguments causes it to prompt
>>>for a
>>>.FRM or .BAS source file. Instead I fed it the name of the .MAK file to
>>>see
>>>what explodes. It duly offered name.OBJ as the output file, then
>>>proceeded to
>>>report errors as follows:
>>>
>>>Source listing [nul.lst]:
>>>
>>>0030 0006 PSTART.FRM
>>> ^ Equal sign missing
>>>0030 0006 etc for the remaining modules.
>>>-and-
>>> 0 Warning error(s)
>>> 6 Severe error(s)
>>>
>>>Any idea what it is on about? Is this just BC choking on a .MAK as as
>>>undecipherable format, thinking the module names are LHS of expressions?
>>
>>BC doesn't know anything about .MAK files.
>
> I fully expected that, but figured i couldn't break it by trying
>
> (snip)
>
>>Anyway, if you want, zip up all of your source, .mak and include
>>files, and email to my (unscrambled) email address, I will write up
>>the necessary batch file, and see if it works. Except for compiling
>>it, I probably wouldn't even bother to look at the files (except to
>>fix errors, if any).
>
> Tnx for the offer - winging its way as I type this. Don't look to
> closely.
>
> Tnx and good luck making sense of it.