Is it worth bothering with other menu/window frameworks?

[Jim Leonard]

(The recent talk about Object Professional prompted me to think about
UIs, so hopefully this is of interest to the helpful folk out there)

I'm finishing up the first milestone of a TP7 project(*) and one of
the requirements was that the total size of the executable code
couldn't exceed 64K. To do this, and to flex my new OOP muscles, I
wrote my own screen handling, input, and windowing routines. They are
extremely basic, but they work for what they were designed for, and my
compiled code does indeed come in under 64K.

The next milestone in the project will require much more sophisticated
user input/output, and the code size limit has been doubled for the
milestone. With 128K of codespace at my disposal, I was checking out
various user interface frameworks:

- Object Professional (OOP)
- Technojocks Turbo Toolkit (v5.1, procedural)
- Technojocks Object Toolkit (v1.10, OOP)
- Technojocks GOLD (v1.0, back to procedural? I wonder why he did
that)
- Turbo Vision (OOP)

I tested them by compiling the demo programs with the features I'd
need (user input, screen handling, windows, menus, input fields, and a
file/directory selector). For all five listed above, I was astonished
to find that the basic level of support for those functions was
100-250KB, which seems very excessive.

My question: Since all of them were bloated (for my needs), is there
any reason to use anything other than Turbo Vision? I say this
because, while I anticipate a learning curve, a lot of people are used
to it, plus I have the manual so hopefully it will serve as a good
tutorial for figuring it out.

Maybe another way of asking my question is: Is there a better
framework out there that I missed for TP7?

(*) If you're curious, the project is MONOTONE; explanation and source
code is here: http://www.oldskool.org/pc/MONOTONE

[Robert AH Prins]

Post by Jim Leonard
(The recent talk about Object Professional prompted me to think about
UIs, so hopefully this is of interest to the helpful folk out there)
I'm finishing up the first milestone of a TP7 project(*) and one of
the requirements was that the total size of the executable code
couldn't exceed 64K. To do this, and to flex my new OOP muscles, I
wrote my own screen handling, input, and windowing routines. They are
extremely basic, but they work for what they were designed for, and my
compiled code does indeed come in under 64K.
The next milestone in the project will require much more sophisticated
user input/output, and the code size limit has been doubled for the
milestone. With 128K of codespace at my disposal, I was checking out
- Object Professional (OOP)
- Technojocks Turbo Toolkit (v5.1, procedural)
- Technojocks Object Toolkit (v1.10, OOP)
- Technojocks GOLD (v1.0, back to procedural? I wonder why he did
that)
- Turbo Vision (OOP)
I tested them by compiling the demo programs with the features I'd
need (user input, screen handling, windows, menus, input fields, and a
file/directory selector). For all five listed above, I was astonished
to find that the basic level of support for those functions was
100-250KB, which seems very excessive.
My question: Since all of them were bloated (for my needs), is there
any reason to use anything other than Turbo Vision? I say this
because, while I anticipate a learning curve, a lot of people are used
to it, plus I have the manual so hopefully it will serve as a good
tutorial for figuring it out.
Maybe another way of asking my question is: Is there a better
framework out there that I missed for TP7?
(*) If you're curious, the project is MONOTONE; explanation and source
code is here: http://www.oldskool.org/pc/MONOTONE

Jim,

You might try the units from Jim LeMay QWIK71.ZIP, WNDW70.ZIP and
PULL70.ZIP. Other than looking at the quite impressive demos, I've never
used them...

One source is
http://files.chatnfiles.com/EMS%20Professional%20Shareware/PASUTIL/

LeMay is probably no longer traceable, so support will be unlikely and
source may also be missing... But using SPO (SPO120.ZIP) by Morten
Welinder or any of TurboPower's tools (or IDA Pro), you may be able to
get some of it in assembler, IIRC they were written in assembler, and a
quick look at qwik71.tpu shows a load of .OBJ files, which seems to
confirm this.

Robert

[Jim Leonard]

Post by Jim Leonard
Maybe another way of asking my question is: Is there a better
framework out there that I missed for TP7?

It's poor form to respond to one's own post, but since I only got one
response, let me try asking my question in a different way:

Are there any major reasons for *not* using TurboVision? ie. any
showstopper issues in using it? Is it huge, slow, bloated? Is it
definitely incompatible with X or Y?

I ask because I'm about to write a program that could benefit from a
nice UI that will take data entry from the user, and don't want to
rewrite half the program if TurboVision is the wrong choice.

[Marco van de Voort]

Post by Jim Leonard

Post by Jim Leonard
Maybe another way of asking my question is: Is there a better
framework out there that I missed for TP7?

It's poor form to respond to one's own post, but since I only got one
Are there any major reasons for *not* using TurboVision? ie. any
showstopper issues in using it? Is it huge, slow, bloated?

That's a question that is a matter of taste or limited requirements.
Yes it is is bloated. On a 386.

Post by Jim Leonard
Is it definitely incompatible with X or Y?

It is eventdriven, which means a different paradigm.

Post by Jim Leonard
I ask because I'm about to write a program that could benefit from a
nice UI that will take data entry from the user, and don't want to
rewrite half the program if TurboVision is the wrong choice.

TV is designed for that, and other than TV/FV in Free Pascal I can't think
of something better for textmode.

[Jim Leonard]

Post by Marco van de Voort
That's a question that is a matter of taste or limited requirements.
Yes it is is bloated. On a 386.

Believe it or not, my target platform is in that class. But speed
isn't a problem, it's size. I compiled a few example applications to
overlays and using the overlay manager; they appear to work fine. Is
this inviting trouble? ie. Should TV never be overlaid?

[Marco van de Voort]

Post by Jim Leonard

Post by Marco van de Voort
That's a question that is a matter of taste or limited requirements.
Yes it is is bloated. On a 386.

Believe it or not, my target platform is in that class. But speed
isn't a problem, it's size. I compiled a few example applications to
overlays and using the overlay manager; they appear to work fine. Is
this inviting trouble? ie. Should TV never be overlaid?

No idea.

While I dabbled with TV a bit when I was still doing TP, my more major TV
experience was already in FPC times. And then that kind of problems kind of
doesn't exist.

[Sv. Broholm]

Post by Marco van de Voort

Post by Marco van de Voort
That's a question that is a matter of taste or limited requirements.
Yes it is is bloated. On a 386.

Believe it or not, my target platform is in that class.  But speed
isn't a problem, it's size.  I compiled a few example applications to
overlays and using the overlay manager; they appear to work fine.  Is
this inviting trouble?  ie. Should TV never be overlaid?

No idea.
While I dabbled with TV a bit when I was still doing TP, my more major TV
experience was already in FPC times. And then that kind of problems kind of
doesn't exist.

If size matters (<64 kB) - and I assume you have much available memory
- then use the overlay manager as you already have done, and copy the
overlaid units to either EMS- or EXT-ram. That will not harm
performance. I assume you will have quite many units overlaid, so the
overlay buffer might be expanded a bit for performace reasons, but you
will very quickly run into problems with your chosen 64 kB memory
limit. With the overlay analyzer, PSA from Turbo Analyst (Turbo Power
Software), you can fine tune unitsizes and see which overlays get
called alot and which is only called a few times.

Keep us posted.

[Jim Leonard]

Post by Sv. Broholm
If size matters (<64 kB) - and I assume you have much available memory
- then use the overlay manager as you already have done, and copy the
overlaid units to either EMS- or EXT-ram. That will not harm

EMS is not available on the target platform.

Some details are probably needed at this point: I am writing a
discovery and benchmarking program specifically targeted toward very
old PCs, for a growing hobbyist community around these old machines.
I am trying to keep the code size to 360K (to fit onto a single 5.25"
disk, which is sometimes all these old machines have), and memory
usage to around 80K of (to work on machines with 128MB RAM).

The code (TV not withstanding!) is very large, as it contains a lot of
routines to detect various graphics cards, processors, and speeds.
Since only 1% of these routines will ever get run on any one machine
(e.g. the Pentium/CPUID routines never run if the CPU gets detected as
a 386, etc.), they don't all need to go into memory at once, so I will
definitely be using the overlay manager for those. My concern is
whether or not TV elements can also be overlaid. I assume trying to
overlay the mouse routines would be disastrous, as they are interrupt-
driven, but is there anything else I should definitely NOT overlay?

Post by Sv. Broholm
With the overlay analyzer, PSA from Turbo Analyst (Turbo Power
Software), you can fine tune units izes and see which overlays get
called alot and which is only called a few times.

Unfortunately, Turbo Power has neglected to opensource their pascal
offerings, only their C/C++ offerings. Is there any way to obtain
PSA? (If not, I can comb through .MAP files, but it would be really
nice to have a pre-written utility to do that for me)

[Marco van de Voort]

Post by Jim Leonard
The code (TV not withstanding!) is very large, as it contains a lot of
routines to detect various graphics cards, processors, and speeds.
Since only 1% of these routines will ever get run on any one machine
(e.g. the Pentium/CPUID routines never run if the CPU gets detected as
a 386, etc.), they don't all need to go into memory at once, so I will
definitely be using the overlay manager for those. My concern is
whether or not TV elements can also be overlaid. I assume trying to
overlay the mouse routines would be disastrous, as they are interrupt-
driven, but is there anything else I should definitely NOT overlay?

I think core TV is pretty monolithical, but I guess in TP that's sub 100k.

Since anything popped up via a menu or key can probably be in an overlay,
you could overlay nearly anything you customize (custom dialogs, but e.g.
also non core TV widgets as the calculator).

Limiting the number of distinct widget types keeps memory down too.
(smartlinking). Avoid very complex widgets as file open and treeviews, which
are larger than the rest.

How to overlay the stuff you actually program depends on how it works. If
detections are guided by a series of dialogs, is different from just running
detections in batch and then presented in a result screen.

In the former case you bundle in each ovl the detections and the forms (e.g.
that make choices or provide intermediate results), and in the latter you
run the detections, and then load all custom dialogs in a presentation
dialog.

Note that IIRC, TV allows to stream dialogs to file, to avoid having to have
code in the binary to create dialogs. (with a lot of dialog, the streaming
code is way smaller than the dialog creations-in-code)

P.s. In case you _really_ need to use some memory, use a 64-bit FPC :-)

[Jim Leonard]

Post by Marco van de Voort
Note that IIRC, TV allows to stream dialogs to file, to avoid having to have
code in the binary to create dialogs. (with a lot of dialog, the streaming
code is way smaller than the dialog creations-in-code)

Now that is something I never knew. Hopefully the Turbo Vision manual
will cover it?

[Sv. Broholm]

Post by Jim Leonard

Post by Sv. Broholm
If size matters (<64 kB) - and I assume you have much available memory
- then use the overlay manager as you already have done, and copy the
overlaid units to either EMS- or EXT-ram. That will not harm

EMS is not available on the target platform.
Some details are probably needed at this point:  I am writing a
discovery and benchmarking program specifically targeted toward very
old PCs, for a growing hobbyist community around these old machines.
I am trying to keep the code size to 360K (to fit onto a single 5.25"
disk, which is sometimes all these old machines have),

If codesize should be less than 360 kB then use PKLITE to reduce the
compiled EXE-size.
Shriks normally to around 40 % of org.size.

Post by Jim Leonard
and memory usage to around 80K of (to work on machines with 128MB RAM).

With 128 *MB* RAM you have no problems ;-)
Turbo3 compiles to tiny COM-files and can use overlays as well. Limits
to 64 kB load image. But you shall write your own interface :-(

I understand that the loadsize of the program must not be larger than
approx 80 kB - incl overlay buffer ? I suggest approx 100 kB incl.
overlay buffer around 50 kB. It must be larger than the biggest
overlaid unit (codesize).

Post by Jim Leonard
The code (TV not withstanding!) is very large, as it contains a lot of
routines to detect various graphics cards, processors, and speeds.
Since only 1% of these routines will ever get run on any one machine
(e.g. the Pentium/CPUID routines never run if the CPU gets detected as
a 386, etc.), they don't all need to go into memory at once, so I will
definitely be using the overlay manager for those.  My concern is
whether or not TV elements can also be overlaid.  I assume trying to
overlay the mouse routines would be disastrous, as they are interrupt-
driven, but is there anything else I should definitely NOT overlay?

Units that contain interrupthandlers (mouse-unit) and
Units that loads BGI-fonts and BGI-drivers must never be overlaid.

Post by Jim Leonard

Post by Sv. Broholm
With the overlay analyzer, PSA from Turbo Analyst (Turbo Power
Software), you can fine tune units izes and see which overlays get
called alot and which is only called a few times.

Unfortunately, Turbo Power has neglected to opensource their pascal
offerings, only their C/C++ offerings.  Is there any way to obtain
PSA?  (If not, I can comb through .MAP files, but it would be really
nice to have a pre-written utility to do that for me)

It should be in your mailbox!

[Jim Leonard]

Post by Sv. Broholm

Post by Jim Leonard

Post by Sv. Broholm
With the overlay analyzer, PSA from Turbo Analyst (Turbo Power
Software), you can fine tune units izes and see which overlays get
called alot and which is only called a few times.

Unfortunately, Turbo Power has neglected to opensource their pascal
offerings, only their C/C++ offerings. Is there any way to obtain
PSA? (If not, I can comb through .MAP files, but it would be really
nice to have a pre-written utility to do that for me)

It should be in your mailbox!

Thank you sir!

[Sv. Broholm]

Post by Sv. Broholm

Post by Jim Leonard

Post by Sv. Broholm
If size matters (<64 kB) - and I assume you have much available memory
- then use the overlay manager as you already have done, and copy the
overlaid units to either EMS- or EXT-ram. That will not harm

EMS is not available on the target platform.
Some details are probably needed at this point:  I am writing a
discovery and benchmarking program specifically targeted toward very
old PCs, for a growing hobbyist community around these old machines.
I am trying to keep the code size to 360K (to fit onto a single 5.25"
disk, which is sometimes all these old machines have),

If codesize should be less than 360 kB then use PKLITE to reduce the
compiled EXE-size.
Shriks normally to around 40 % of org.size.

Post by Jim Leonard
and memory usage to around 80K of (to work on machines with 128MB RAM).

With 128 *MB* RAM you have no problems  ;-)
Turbo3 compiles to tiny COM-files and can use overlays as well. Limits
to 64 kB load image. But you shall write your own interface :-(
I understand that the loadsize of the program must not be larger than
approx 80 kB - incl overlay buffer ? I suggest approx 100 kB incl.
overlay buffer around 50 kB. It must be larger than the biggest
overlaid unit (codesize).

Post by Jim Leonard
The code (TV not withstanding!) is very large, as it contains a lot of
routines to detect various graphics cards, processors, and speeds.
Since only 1% of these routines will ever get run on any one machine
(e.g. the Pentium/CPUID routines never run if the CPU gets detected as
a 386, etc.), they don't all need to go into memory at once, so I will
definitely be using the overlay manager for those.  My concern is
whether or not TV elements can also be overlaid.  I assume trying to
overlay the mouse routines would be disastrous, as they are interrupt-
driven, but is there anything else I should definitely NOT overlay?

Units that contain interrupthandlers (mouse-unit) and
Units that loads BGI-fonts and BGI-drivers must never be overlaid.

Post by Jim Leonard

Post by Sv. Broholm
With the overlay analyzer, PSA from Turbo Analyst (Turbo Power
Software), you can fine tune units izes and see which overlays get
called alot and which is only called a few times.

Unfortunately, Turbo Power has neglected to opensource their pascal
offerings, only their C/C++ offerings.  Is there any way to obtain
PSA?  (If not, I can comb through .MAP files, but it would be really
nice to have a pre-written utility to do that for me)

If your application must run on a DOS-computer with max 128 Kb RAM you
are in big problems using TurboVision!

Installed RAM 128 kB
- for DOS -45 kB
- MouseDriver -5 kB
Available for app. 75 kB

I have used FILEVIEW.PAS and TVDEMO.PAS to see how much memory is
required for a minimal overlaid TV-application.

Even if you fine tune stacksize and use maximum number of TV-units in
overlay, it is difficult to reduce loadsize (Use EXEMOD to determine
actual loadsize = RAM required to run your application) much below 75
kB for a stripped down TV-application. When you add you own code you
get stuck in a very short time.

Bottomline : You can't get your proposed TV-application running with
only 128 kB installed RAM. At least 64 kB extra is required. I still
believe your program can be distributed using a 5.25" floppy with only
360 kB.

If you insist of using only 128 kB RAM then my best idea is using
Turbo3 with overlay's and shoehorn it down using your own simple text
user interface - but it is time consuming - and not rewarding.

[Jim Leonard]

Post by Sv. Broholm
I have used FILEVIEW.PAS and TVDEMO.PAS to see how much memory is
required for a minimal overlaid TV-application.

That is an excellent suggestion. Doing the same, and more importantly
checking TVRDEMO (note the "R", which denotes a size-optimized
overlaid version), I have confirmed there is no way I can meet a 128KB
computer (~96KB free) as a target. TVRDEMO, using overlays, required
162KB just for initialization, and when I "touched" every function, it
ended up using 174KB (but the disk swapping was almost prohibitive).
Even a basic (non-overlaid) myapp.init/run/done used 56K, which is
hopeful, but I wouldn't want to start adding functionality only to
find that I have surpassed my target.

Being as it is not a word processor or anything that *needs* a strong
interface, I'll write my own.

Post by Sv. Broholm
Bottomline : You can't get your proposed TV-application running with
only 128 kB installed RAM. At least 64 kB extra is required. I still
believe your program can be distributed using a 5.25" floppy with only
360 kB.

I concur.

For the curious, there is *one* machine that is *required* to run this
benchmark, only because it has the unique distinction of being the
only IBM machine *slower* than the original PC: The PCjr. One of the
questions this benchmark is supposed to answer is exactly how much
slower it was. Most PCjrs are 128KB so I will make that my target.

Post by Sv. Broholm
If you insist of using only 128 kB RAM then my best idea is using
Turbo3 with overlay's and shoehorn it down using your own simple text
user interface - but it is time consuming - and not rewarding.

I disagree with this, because Turbo3 actually produced bigger and
worse code than Turbo7. Turbo7 has a lot of compiler optimizations.

[Sv. Broholm]

Post by Jim Leonard
Being as it is not a word processor or anything that *needs* a strong
interface, I'll write my own.

Post by Sv. Broholm
Bottomline : You can't get your proposed TV-application running with
only 128 kB installed RAM. At least 64 kB extra is required. I still
believe your program can be distributed using a 5.25" floppy with only
360 kB.

I concur.
For the curious, there is *one* machine that is *required* to run this
benchmark, only because it has the unique distinction of being the
only IBM machine *slower* than the original PC:  The PCjr.  One of the
questions this benchmark is supposed to answer is exactly how much
slower it was.  Most PCjrs are 128KB so I will make that my target.

So you skip TV-interface and carry on with your own, simple user
interface and overlaid units using up to 96 kB free RAM and TP7 ?
Remember buffersize, stack and heap + codespace should all sum up to
less than 96 kB. I estimate following:
Buffersize 25 kB "large" buffer to reduce disk trashing on a
slow computer.
Stack size 10 kB
Heap 7 kB
Overlay manager 3 kB
Total 45 kB

Thus code and data space is 96 kB - 46 kB = 50 kB

It will be tough!. Keep us posted.

Post by Jim Leonard

Post by Sv. Broholm
If you insist of using only 128 kB RAM then my best idea is using
Turbo3 with overlay's and shoehorn it down using your own simple text
user interface - but it is time consuming - and not rewarding.

I disagree with this, because Turbo3 actually produced bigger and
worse code than Turbo7.  Turbo7 has a lot of compiler optimizations.

The initial overhead to produce a small TP3 application (includes
SYSTEM, DOS, and CRT-unit) is 10 kB COM-filesize compared to 4 kB EXE-
filesize compiled with TP7. But for larger programs this differences
changes in favour of TP3, because TP3 produces code to tiny memory
model - thus references to registers are smaller.
Keep us posted !

[Jim Leonard]

Post by Sv. Broholm
So you skip TV-interface and carry on with your own, simple user
interface and overlaid units using up to 96 kB free RAM and TP7 ?
Remember buffersize, stack and heap + codespace should all sum up to
Buffersize 25 kB "large" buffer to reduce disk trashing on a
slow computer.
Stack size 10 kB
Heap 7 kB
Overlay manager 3 kB
Total 45 kB
Thus code and data space is 96 kB - 46 kB = 50 kB
It will be tough!. Keep us posted.

It will be easier than that :-) I wrote an OOP music composition
program more complex than my current project and it was still under
those numbers (http://www.oldskool.org/pc/MONOTONE if you're curious,
full source included).

Post by Sv. Broholm
Keep us posted !

Will do :-)

I am going through the TV tutorial in the TV programming guide. It is
very slow going, but I am interested in how TCollection works because
I have to maintain a small database. I was going to write my own
routines (linked list, text-based flat file) but if TCollection
already does that then I will just look at that.

If I can understand TV enough (already the status line and menu build
linked lists nested levels are irritating me) I might go ahead and
write the entire thing in TV, then write a smaller utility program
that does the basic system identification/benchmarking and writes it
to a file that the larger program can then import.

[Marco van de Voort]

Post by Jim Leonard
I am going through the TV tutorial in the TV programming guide. It is
very slow going, but I am interested in how TCollection works because

IIRC TCollection is roughly Delphi's TList, which means it is a simple array
of pointers wrapped in a class. Not the best for scalability, but for you
that's less of a problem.

TCollection is part of Objects, thus the base RTL, and not TV btw.

Post by Jim Leonard
If I can understand TV enough (already the status line and menu build
linked lists nested levels are irritating me) I might go ahead and
write the entire thing in TV, then write a smaller utility program
that does the basic system identification/benchmarking and writes it
to a file that the larger program can then import.

I'm gearing up to do some FV/TV work in the FPC ide. (letting a listbox
popup on an outline); so keep asking questions. I do have some TV books,
but the main one I use is Dutch. (the TV reference guide of BP7 is
ultimately resource but more of a reference than a tutorial. The Dutch book
is better)

[Jason Burgon]

Post by Marco van de Voort
TCollection is part of Objects, thus the base RTL, and not TV btw.

Not strictly true. OBJECTS.PAS is part of TV and Object Windows, so is not
part of the BP7 RTL. However, one can use OBJECTS.PAS without dragging in
any of the UI units of either Turbo Vision or OWL.

Jay
--

Jason Burgon - author of Graphic Vision
http://homepage.ntlworld.com/gvision

[Marco van de Voort]

Post by Jason Burgon

Post by Marco van de Voort
TCollection is part of Objects, thus the base RTL, and not TV btw.

Not strictly true. OBJECTS.PAS is part of TV and Object Windows, so is not
part of the BP7 RTL. However, one can use OBJECTS.PAS without dragging in
any of the UI units of either Turbo Vision or OWL.

My bad. It is in the RTL in FPC.

There the RTL is loosely defined as "anything the compiler needs to
bootstrap". And since 1.0.x was objects based, it is in the RTL. (and I just
tested, 2.0 still has an objects dependancy where it interfaces the (TV)
textmode IDE. The main objects are Delphi classes based though).

The visual<-> non visual unit is where I would have intuitively put the border
too.