Is it worth bothering with other menu/window frameworks?

(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

"Jim Leonard" <MobyGamer@gmail.com> wrote in message
news:58f0f1ed-4291-42b2-b1e9-a71db353a540@e53g2000hsa.googlegroups.com...
> (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

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%20Pr...eware/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
--
Robert AH Prins
robert dot ah dot prins on gmail

On Jun 18, 10:55 pm, Jim Leonard <MobyGa...@gmail.com> wrote:
> 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.

On 2008-08-07, Jim Leonard <MobyGamer@gmail.com> wrote:
>> 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?

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

> Is it definitely incompatible with X or Y?

It is eventdriven, which means a different paradigm.

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

On Aug 7, 2:26 am, Marco van de Voort <mar...@stack.nl> wrote:
> 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?

On 2008-08-11, Jim Leonard <MobyGamer@gmail.com> wrote:
>> 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.

On 11 Aug., 09:10, Marco van de Voort <mar...@stack.nl> wrote:
> On 2008-08-11, Jim Leonard <MobyGa...@gmail.com> wrote:
>
> >> 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.

On Aug 11, 11:42 am, "Sv. Broholm" <sbroh...@gmail.com> wrote:
> 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?

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

On 2008-08-11, Jim Leonard <MobyGamer@gmail.com> wrote:
> 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 :-)

On 11 Aug., 19:41, Jim Leonard <MobyGa...@gmail.com> wrote:
> On Aug 11, 11:42 am, "Sv. Broholm" <sbroh...@gmail.com> wrote:
>
> > 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.


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

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

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