Discussion:
AHhhhhhhhhhhhh I need VB DOS
(too old to reply)
SomeWhereOverTheRainbow
2004-05-02 20:21:32 UTC
Permalink
Hi,

I've got hold of a oldish handheld pen based barcode scanner but will
only be programmed in either:-

VB/DOS
PenPay
PenRight!

I've managed to get a hold of the SDK (from the device manufacture -
Symbol) for the device but they can't help me to get a hold of a
compiler/interpreter.

I've spent a good few hours hunting for a suitable compiler, but can't
find any sources, Even to buy!

Any help?

TIA,
M.
a***@NOW.AT.arargh.com
2004-05-02 21:33:10 UTC
Permalink
On Sun, 02 May 2004 21:21:32 +0100, SomeWhereOverTheRainbow
Post by SomeWhereOverTheRainbow
I've got hold of a oldish handheld pen based barcode scanner but will
only be programmed in either:-
VB/DOS
PenPay
PenRight!
I've managed to get a hold of the SDK (from the device manufacture -
Symbol) for the device but they can't help me to get a hold of a
compiler/interpreter.
Unless the SDK was written in VBDOS, and requires the VBDOS runtime,
you should be able to use most any 16-bit compiler or assembler. I
know I could. Another way is to just decompile/desassemble the SDK
and see what it does.
--
Arargh404 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.
SomeWhereOverTheRainbow
2004-05-02 22:32:03 UTC
Permalink
Post by a***@NOW.AT.arargh.com
On Sun, 02 May 2004 21:21:32 +0100, SomeWhereOverTheRainbow
Post by SomeWhereOverTheRainbow
I've got hold of a oldish handheld pen based barcode scanner but will
only be programmed in either:-
VB/DOS
PenPay
PenRight!
I've managed to get a hold of the SDK (from the device manufacture -
Symbol) for the device but they can't help me to get a hold of a
compiler/interpreter.
Unless the SDK was written in VBDOS, and requires the VBDOS runtime,
you should be able to use most any 16-bit compiler or assembler. I
know I could. Another way is to just decompile/desassemble the SDK
and see what it does.
Thanks for the advice.

However I fancied a compiler with built in graphics support. The
Stylus pen can be used as a mouse. I've used Borland Turbo C under
DOS. And Embeded C, But they don't (easily) do GUI.

Can you recomend owt?

Ta.
a***@NOW.AT.arargh.com
2004-05-02 23:33:39 UTC
Permalink
On Sun, 02 May 2004 23:32:03 +0100, SomeWhereOverTheRainbow
Post by SomeWhereOverTheRainbow
Post by a***@NOW.AT.arargh.com
On Sun, 02 May 2004 21:21:32 +0100, SomeWhereOverTheRainbow
<snip>
Post by SomeWhereOverTheRainbow
Post by a***@NOW.AT.arargh.com
Post by SomeWhereOverTheRainbow
I've managed to get a hold of the SDK (from the device manufacture -
Symbol) for the device but they can't help me to get a hold of a
compiler/interpreter.
Unless the SDK was written in VBDOS, and requires the VBDOS runtime,
you should be able to use most any 16-bit compiler or assembler. I
know I could. Another way is to just decompile/desassemble the SDK
and see what it does.
Thanks for the advice.
However I fancied a compiler with built in graphics support. The
Stylus pen can be used as a mouse. I've used Borland Turbo C under
DOS. And Embeded C, But they don't (easily) do GUI.
Can you recomend owt?
Noe really. It depends on what the SDK requires. Got a URL for the
SDK?

However, QB45, PDS 7.x MS C 6,7,8 are all 16-bit compilers that have
graphics ability.
--
Arargh404 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.
Derek Ross
2004-05-03 14:46:52 UTC
Permalink
Post by a***@NOW.AT.arargh.com
On Sun, 02 May 2004 23:32:03 +0100, SomeWhereOverTheRainbow
Post by SomeWhereOverTheRainbow
Post by a***@NOW.AT.arargh.com
On Sun, 02 May 2004 21:21:32 +0100, SomeWhereOverTheRainbow
<snip>
Post by SomeWhereOverTheRainbow
Post by a***@NOW.AT.arargh.com
Post by SomeWhereOverTheRainbow
I've managed to get a hold of the SDK (from the device manufacture -
Symbol) for the device but they can't help me to get a hold of a
compiler/interpreter.
Unless the SDK was written in VBDOS, and requires the VBDOS runtime,
you should be able to use most any 16-bit compiler or assembler. I
know I could. Another way is to just decompile/desassemble the SDK
and see what it does.
Thanks for the advice.
However I fancied a compiler with built in graphics support. The
Stylus pen can be used as a mouse. I've used Borland Turbo C under
DOS. And Embeded C, But they don't (easily) do GUI.
Can you recomend owt?
Noe really. It depends on what the SDK requires. Got a URL for the
SDK?
However, QB45, PDS 7.x MS C 6,7,8 are all 16-bit compilers that have
graphics ability.
It seems to me that your two options are:

1) Keep an eye on eBay's BASIC items. VBDOS comes up from time to time
and you may get lucky.
2) Check http://www.emsps.com/oldtools/msvb.htm which has a selection
of second-hand VBDOS packages at not unreasonable prices.

The second option is generally more expensive than the first but you
are paying for instant purchase as opposed to waiting for what you
want to appear on eBay.

Cheers

Derek
a***@NOW.AT.arargh.com
2004-05-03 20:48:29 UTC
Permalink
Post by Derek Ross
Post by a***@NOW.AT.arargh.com
On Sun, 02 May 2004 23:32:03 +0100, SomeWhereOverTheRainbow
Post by SomeWhereOverTheRainbow
Post by a***@NOW.AT.arargh.com
On Sun, 02 May 2004 21:21:32 +0100, SomeWhereOverTheRainbow
<snip>
Post by SomeWhereOverTheRainbow
Post by a***@NOW.AT.arargh.com
Post by SomeWhereOverTheRainbow
I've managed to get a hold of the SDK (from the device manufacture -
Symbol) for the device but they can't help me to get a hold of a
compiler/interpreter.
Unless the SDK was written in VBDOS, and requires the VBDOS runtime,
you should be able to use most any 16-bit compiler or assembler. I
know I could. Another way is to just decompile/desassemble the SDK
and see what it does.
Thanks for the advice.
However I fancied a compiler with built in graphics support. The
Stylus pen can be used as a mouse. I've used Borland Turbo C under
DOS. And Embeded C, But they don't (easily) do GUI.
Can you recomend owt?
Noe really. It depends on what the SDK requires. Got a URL for the
SDK?
However, QB45, PDS 7.x MS C 6,7,8 are all 16-bit compilers that have
graphics ability.
Not mine, the OP's. Assumming he really needs VBDOS.
Post by Derek Ross
1) Keep an eye on eBay's BASIC items. VBDOS comes up from time to time
and you may get lucky.
2) Check http://www.emsps.com/oldtools/msvb.htm which has a selection
of second-hand VBDOS packages at not unreasonable prices.
The second option is generally more expensive than the first but you
are paying for instant purchase as opposed to waiting for what you
want to appear on eBay.
And, of course, the 3rd illegal option of finding a copy on the web.
--
Arargh404 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.
Derek Ross
2004-05-04 14:49:11 UTC
Permalink
Post by a***@NOW.AT.arargh.com
Not mine, the OP's. Assumming he really needs VBDOS.
My apologies. My comments were aimed at the OP but I can see that it
didn't look like that.

Cheers

Derek
a***@NOW.AT.arargh.com
2004-05-04 20:19:22 UTC
Permalink
Post by Derek Ross
Post by a***@NOW.AT.arargh.com
Not mine, the OP's. Assumming he really needs VBDOS.
My apologies. My comments were aimed at the OP but I can see that it
didn't look like that.
No problem. The thread is starting to get to the point where who
wrote what where is getting somewhat confusing.
--
Arargh404 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.
Dan Barc;au
2004-05-04 16:03:30 UTC
Permalink
I'm not following exactly what you're looking for here, but be aware that
the "V" in VBDOS is a *character* based user interface, not graphic. If
you're really looking for a graphic interface, VBDOS does graphics exactly
the same way as previous versions of Basic did. In fact, other than the
(character based) forms engine and a couple of other internal goodies
(overlay manager, etc), VBDOS is simply a "newer version" of previous MS
Basic DOS products.

Dan
Post by SomeWhereOverTheRainbow
Post by a***@NOW.AT.arargh.com
On Sun, 02 May 2004 21:21:32 +0100, SomeWhereOverTheRainbow
Post by SomeWhereOverTheRainbow
I've got hold of a oldish handheld pen based barcode scanner but will
only be programmed in either:-
VB/DOS
PenPay
PenRight!
I've managed to get a hold of the SDK (from the device manufacture -
Symbol) for the device but they can't help me to get a hold of a
compiler/interpreter.
Unless the SDK was written in VBDOS, and requires the VBDOS runtime,
you should be able to use most any 16-bit compiler or assembler. I
know I could. Another way is to just decompile/desassemble the SDK
and see what it does.
Thanks for the advice.
However I fancied a compiler with built in graphics support. The
Stylus pen can be used as a mouse. I've used Borland Turbo C under
DOS. And Embeded C, But they don't (easily) do GUI.
Can you recomend owt?
Ta.
a***@NOW.AT.arargh.com
2004-05-04 20:17:48 UTC
Permalink
Post by Dan Barc;au
I'm not following exactly what you're looking for here, but be aware that
the "V" in VBDOS is a *character* based user interface, not graphic. If
you're really looking for a graphic interface, VBDOS does graphics exactly
the same way as previous versions of Basic did. In fact, other than the
(character based) forms engine and a couple of other internal goodies
(overlay manager, etc), VBDOS is simply a "newer version" of previous MS
Basic DOS products.
But not enough better to bother with.
--
Arargh404 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.
Dan Barclay
2004-05-05 05:43:10 UTC
Permalink
Post by a***@NOW.AT.arargh.com
Post by Dan Barc;au
I'm not following exactly what you're looking for here, but be aware that
the "V" in VBDOS is a *character* based user interface, not graphic. If
you're really looking for a graphic interface, VBDOS does graphics exactly
the same way as previous versions of Basic did. In fact, other than the
(character based) forms engine and a couple of other internal goodies
(overlay manager, etc), VBDOS is simply a "newer version" of previous MS
Basic DOS products.
But not enough better to bother with.
In general, I agree. The exception (for me) was the MOVE overlay manager.
That one was actually very nice! There is no way I could have created the
app I had without it. It actually came out of development for C++, but was
included with VBDOS in order to be compatible cross-language.

I didn't use the (V) part except to play around. I already had very good UI
libraries and saw no need to change. Besides, using a single function from
the forms engine (even a MsgBox()) sucked in the entire forms library at
300k.

Dan
a***@NOW.AT.arargh.com
2004-05-05 06:15:07 UTC
Permalink
On Wed, 5 May 2004 00:43:10 -0500, "Dan Barclay" <***@MVPs.org> wrote:

<snip>
Post by Dan Barclay
Post by a***@NOW.AT.arargh.com
But not enough better to bother with.
In general, I agree. The exception (for me) was the MOVE overlay manager.
That one was actually very nice! There is no way I could have created the
app I had without it. It actually came out of development for C++, but was
included with VBDOS in order to be compatible cross-language.
I didn't use the (V) part except to play around. I already had very good UI
libraries and saw no need to change. Besides, using a single function from
the forms engine (even a MsgBox()) sucked in the entire forms library at
300k.
That's worse than using 'VAL' - the fp code isn't all that big.

Someone I know had written a large application in PDS and was using
the EMS overlay whatever. I had been working on a replacement runtime
for PDS, that runs with Pharlaps 286|dos extender. By the time the
project finished, the EXE size was up to about 1.7 meg, and no more
overlays.

BTW, I wrote a MsgBox subroutine, for PDS in PDS. Maybe 2k?
--
Arargh404 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.
Dan Barclay
2004-05-09 03:27:41 UTC
Permalink
Yup, I had a MsgBox in asm... don't remember the size but it sure didn't
break 2k<g>.

I had a lot of my own library, until I hired Microhelp and Crescent as part
time programmers<g>. That was, of course, in the days when you could count
on the vendors and source was automatic.

The MOVE manager was great if you didn't have full control over the target
machines, which was the case with our apps. We were selling into the
corporate market where different customers were fighting the memory battle
differently. MOVE let my 1-2meg exe run easily in less than 300k... which
was what was left after various network clients, record managers, and 3270
emulators were installed.

PDS had a static overlay manager, which I fooled with, but it didn't come
close to the flexibility or performance of MOVE.

Dan
Post by a***@NOW.AT.arargh.com
<snip>
Post by Dan Barclay
Post by a***@NOW.AT.arargh.com
But not enough better to bother with.
In general, I agree. The exception (for me) was the MOVE overlay manager.
That one was actually very nice! There is no way I could have created the
app I had without it. It actually came out of development for C++, but was
included with VBDOS in order to be compatible cross-language.
I didn't use the (V) part except to play around. I already had very good UI
libraries and saw no need to change. Besides, using a single function from
the forms engine (even a MsgBox()) sucked in the entire forms library at
300k.
That's worse than using 'VAL' - the fp code isn't all that big.
Someone I know had written a large application in PDS and was using
the EMS overlay whatever. I had been working on a replacement runtime
for PDS, that runs with Pharlaps 286|dos extender. By the time the
project finished, the EXE size was up to about 1.7 meg, and no more
overlays.
BTW, I wrote a MsgBox subroutine, for PDS in PDS. Maybe 2k?
--
Arargh404 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.
a***@NOW.AT.arargh.com
2004-05-09 03:37:51 UTC
Permalink
Post by Dan Barclay
Yup, I had a MsgBox in asm... don't remember the size but it sure didn't
break 2k<g>.
My routine didn't get used that much, and was so complicted that I
never bothered to do it in asm.
Post by Dan Barclay
I had a lot of my own library, until I hired Microhelp and Crescent as part
time programmers<g>. That was, of course, in the days when you could count
on the vendors and source was automatic.
I still do (have a lot of my own library). Something just got added
not too long ago. Mine started as a rewrite of some routines that I
didn't like the way Crescent did. And it just keeps getting bigger.
Post by Dan Barclay
The MOVE manager was great if you didn't have full control over the target
machines, which was the case with our apps. We were selling into the
corporate market where different customers were fighting the memory battle
differently. MOVE let my 1-2meg exe run easily in less than 300k... which
was what was left after various network clients, record managers, and 3270
emulators were installed.
PDS had a static overlay manager, which I fooled with, but it didn't come
close to the flexibility or performance of MOVE.
Never tried either, actually.
--
Arargh405 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.
Dan Barclay
2004-05-09 03:53:34 UTC
Permalink
Post by a***@NOW.AT.arargh.com
Post by Dan Barclay
Yup, I had a MsgBox in asm... don't remember the size but it sure didn't
break 2k<g>.
My routine didn't get used that much, and was so complicted that I
never bothered to do it in asm.
Post by Dan Barclay
I had a lot of my own library, until I hired Microhelp and Crescent as part
time programmers<g>. That was, of course, in the days when you could count
on the vendors and source was automatic.
I still do (have a lot of my own library). Something just got added
not too long ago. Mine started as a rewrite of some routines that I
didn't like the way Crescent did. And it just keeps getting bigger.
Interesting. I went the other way <g>. I had mine before those guys really
got started good. Then I found I could buy theirs and spend my time on the
app level coding instead of enhancing my own and adding routines. My low
level (generic) lib kept getting smaller, which let me spend more time on my
specialized libs. What's more, in those days those guys were *looking* for
more routines to add. All you had to do was mention one and it magically
showed up!
Post by a***@NOW.AT.arargh.com
Post by Dan Barclay
The MOVE manager was great if you didn't have full control over the target
machines, which was the case with our apps. We were selling into the
corporate market where different customers were fighting the memory battle
differently. MOVE let my 1-2meg exe run easily in less than 300k... which
was what was left after various network clients, record managers, and 3270
emulators were installed.
PDS had a static overlay manager, which I fooled with, but it didn't come
close to the flexibility or performance of MOVE.
Never tried either, actually.
It doesn't sound like you had reason to try them. Both required a little
thought and design, though it wasn't difficult. Neither are something you'd
use unless you had need, but if you had the need it was *really* slick.

Dan
a***@NOW.AT.arargh.com
2004-05-09 06:11:53 UTC
Permalink
Post by Dan Barclay
It doesn't sound like you had reason to try them. Both required a little
thought and design, though it wasn't difficult. Neither are something you'd
use unless you had need, but if you had the need it was *really* slick.
One main reason was that I wrote that replacement runtime. Using
that, I could stuff several megs of code into the exe, with no
overlays, and have quite a few meg of memory left over for far data.
DGROUP was still 64k, however string space was 900k+.

I had wanted the same kind of abilities for win32, hence BCET. (2nd
URL) Now the only limitation on memory is when windows barfs.
--
Arargh405 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.
Ethan Winer
2004-05-09 12:36:18 UTC
Permalink
Dan,
those guys were *looking* for more routines to add. All you had to do was
mention one and it magically showed up! <

ROF,L. Yes, I remember that well. It was a competition of "routine count"
between me, Mark Novisoff, and Wayne Hammerly. Well, not Wayne of course,
because he didn't actually write any assembly language code. That was Tom
Hanlin.

I always thought Mark should have named his company NovaSoft.

Thanks for the trip down Memory Lane, guys.

--Ethan
Dan Barclay
2004-05-10 04:22:57 UTC
Permalink
Post by Ethan Winer
Dan,
those guys were *looking* for more routines to add. All you had to do was
mention one and it magically showed up! <
ROF,L. Yes, I remember that well. It was a competition of "routine count"
between me, Mark Novisoff, and Wayne Hammerly. Well, not Wayne of course,
because he didn't actually write any assembly language code. That was Tom
Hanlin.
I always thought Mark should have named his company NovaSoft.
I had that same thought<g>. It had to have crossed his mind. Maybe
MicroHelp was to try to link up with MicroSoft?
Post by Ethan Winer
Thanks for the trip down Memory Lane, guys.
I really miss those days. Not for the DOS, but for the vendor group and
developers that actually cared about what they were putting out.

What we're getting today (partucularly from MS) is, well, sad.

MSBasic R.I.P.

I am, unfortunately, about to start wandering over to the Delphi world.
Damn I hate Pascal. But, those guys actually think about their customers
and that does matter. It would be really cool if they could get TurboBasic
back in that mix, but that's not going to happen<sigh>.

Damn I hate Pascal (yea, I know I already said that), but not as much as
C++.

Dan
Bob O`Bob
2004-05-10 07:34:34 UTC
Permalink
Post by Dan Barclay
I really miss those days. Not for the DOS, but for the vendor group and
developers that actually cared about what they were putting out.
Yep. I didn't know but a few of the folks, though I used many of the products.
There was a time and a place when PDQBasic just blew away ...
whatever the heck it was that I had been working with before.
Post by Dan Barclay
What we're getting today (partucularly from MS) is, well, sad.
MSBasic R.I.P.
I am, unfortunately, about to start wandering over to the Delphi world.
Damn I hate Pascal. But, those guys actually think about their customers
and that does matter. It would be really cool if they could get TurboBasic
back in that mix, but that's not going to happen<sigh>.
I recently looked over the PowerBasic site and it seems to be saying
a lot of the things I think are the right ones. Any comments about that?
Post by Dan Barclay
Damn I hate Pascal (yea, I know I already said that), but not as much as
C++.
Hrm. I hate Pascal too.
Would much rather do C++, but I usually end up writing just plain C using C++ tools.
I'd rather be doing Objective-C.

None of it's nearly as nice as VB *could* have grown to, though.


Bob
--
Dan Barclay
2004-05-10 20:40:43 UTC
Permalink
Post by Bob O`Bob
Post by Dan Barclay
I am, unfortunately, about to start wandering over to the Delphi world.
Damn I hate Pascal. But, those guys actually think about their customers
and that does matter. It would be really cool if they could get TurboBasic
back in that mix, but that's not going to happen<sigh>.
I recently looked over the PowerBasic site and it seems to be saying
a lot of the things I think are the right ones. Any comments about that?
I'll look again when I get a chance. When I looked into it a year or more
ago I was left feeling there was a gaping hole for me to fall through. A
lot of things could have happened since then.
Post by Bob O`Bob
Post by Dan Barclay
Damn I hate Pascal (yea, I know I already said that), but not as much as
C++.
Hrm. I hate Pascal too.
Would much rather do C++, but I usually end up writing just plain C using C++ tools.
I'd rather be doing Objective-C.
None of it's nearly as nice as VB *could* have grown to, though.
Yup. Shame. Damned shame. But, they "fixed" it. Maybe the C weenies will
like it now, but I doubt it.

It's gone. Dead.

Dan
Ethan Winer
2004-05-10 13:12:15 UTC
Permalink
Dan,
Damn I hate Pascal <
Aaarrr me hearties, ASM is the most manly language of them all.

:->)

--Ethan
Dan Barclay
2004-05-10 20:35:07 UTC
Permalink
Post by Ethan Winer
Dan,
Damn I hate Pascal <
Aaarrr me hearties, ASM is the most manly language of them all.
As a matter of fact, it is. It doesn't get much better than that.

I just can't figure out how to make any money with it doing applications in
Windoze! What's more, what they call "assembler" in .Net is for real
sissies. Ahhh...for the days when we talked to the big iron using registers
on the IRMA board. Long gone now.

Dan
Ethan Winer
2004-05-11 13:26:48 UTC
Permalink
Dan,
what they call "assembler" in .Net is for real sissies <
ROF,L. I haven't seen that, but I remember well when Microsoft first
"sissified" assembly language. It was the release of MASM 6, when they added
high level language constructs. They actually broke assembly language. If
you used the built-in language macros like IF your code might not work and
you'd have no idea why, because they used AX for intermediate operations! I
still can't get over how lame that was of them.

--Ethan

Loading...