🚀 go-pugleaf

>In article <1992Sep25.222416.19318@microsoft.com> fredf@microsoft.com (Fred Freeland) writes:
>> Obviously it cannot be totally code compatible with Visual Basic for Windows
>> because it runs in a totally different environment and things are handled
>> differently between the two environments. Sorry, this is a fact of life.
>
>	How come ? There are windows, that can very well be drawn without
>	MS Windows. VB doesn't multitask, so that is not a problem either.
The core event code works precisely the same.  You get the same 15 standard
controls, virtual all the same properties, and virtually all the same events.
You even get drag & drop, icons, max and min, and the clipboard.  You cannot
magically get Windows API and DLL calls to work, however.  That's what I think
Fred meant.

>
>> You have very obviously misunderstood what this product is. It is not the
>> programming package for DOS that's going to let you write DOS apps that
>> simply look like they are Windows apps.
>
>	Put that in you adverizements.
Lets get this straight.  What is VB/DOS?
1.  By far the fastest way to create powerful, fast, and robust DOS
applications.  It offers the same Productivty features (draw the UI, events,
etc.), custom controls, etc. that VB/Win pioneered.
2.  Combining VB/DOS and VB/Win is by far the best way I know to get 
identical or nearly identical apps running under the two most popular
PC platforms -- DOS and Windows.
3.  VB/DOS is optimized for DOS programming so it has certain features that
go beyond VB/Win because certain features are requirements for DOS
developers -- such as native code compilers, direct hardware access,
call interrupt, etc.

VB/DOS is not a port of VB/Win to DOS because the product would not have
been appropriate for DOS (lacking features, optimized for different tasks)
Etc.

>
>> DOS is a character-based medium.
>
>	DOS is NOT a character-based medium. DOS has lousy segments, but
>	it can use the mouse and graphical screens. 
You are correct.  VB/DOS uses the mouse and uses graphics.  It simply does
not allow text-mode forms and graphics to be mixed at the same time.  But
you can mix graphics and forms within the same app.  Just a couple of
lines of code, in fact.

>
>> True, there
>> are custom graphical packages that run under DOS, but VB/DOS is not one
>> of them, and is was never advertised as such.
>
>	Visual Basic for DOS. So Visual means character based graphics ?
>	^^^^^^
If you really want to argue about semantics, than I would define VISUAL
as refering to DRAWING as opposed to coding.

>
>> >  (2) You cannot put graphics on forms. This is a BIG, BAD thing as
>> >      far as I am concerned.
>>
>> It's true, you cannot, but that's because the forms ARE NOT graphic. You
>> cannot simply plop down a graphic on a text-based screen where the standard
>> unit of measure is a character-width. 
>
>	If you accept screen, line, pset, etc... You should accept
>	graphical forms too. BTW, even AmigaBASIC written 1985 by MicroSoft
>	can handle multiple windows (Forms).

Yes we should.  But there were a few problems with doing that.
1.  The underlying forms engine in VB/DOS could work in graphics mode but
actually much slower than the painfully hand-optimized Windows graphics
code.  Yes, DOS would have been slower than Windows.
2.  Redundant with VB/Win.  Due to the speed limitations noted above,
you would have needed better hardware to run VB/DOS graphics forms than
for VB/Win.  Not really optimal from a customer point of view.
3.  Memory.  Imagine multiple overlapping forms on the screen.  To get
decent performance, we would have liked to use buffered bitmaps.  Calculate
the memory required for 640*480 bitmapped displays and you start to see
the problem.
4.  Frankly, it would have added considerably to the development cycle.
The product could easily have slipped to mid 1993.  After seeing what
customers wanted to use VB/DOS for (generally text-mode vertical apps)
that slip didn't seem optimal for our customers....especially since folks
with heavy graphics needs already have VB/Win.

Hope that helps,

thanks,
Steve Podradchik, Microsoft Visual Basic for MS-DOS Product Manager