Re: Ideas that didn't come off

Scout wrote:

I do have a Delphi-based invention that I am not willing to share due
to commercial constraints, but I figure that there are lots of Delphi
inventions which sounded good on paper, but which (like mine) didn't
work in practice.

Back in the Turbo Pascal days, I used a discussion BBS that ran on an
Apple ][. (That's where I met my SO, but that's another story.) The
sysop had made a bundle at Atari, and had written his BBS in
assembler, and so got a fair amount of respect from the user
community. He had this dream of writing a multi-user BBS, in 68K
assembler on top of a custom OS, that would be linked, system to
system, so you'd have local discussions and national email. He never
got farther than persuading some people to invest enough to buy a
rather expensive development box, but multi-tasking was on my mind for
a while.

I had written a few state machines, for things like protocol handling
and terminal emulation, and I had the bright idea that a state machine
could be a very efficient multitasker. Instead of doing a preemptive
task switch, which involves saving and restoring registers and
maintaining multiple stacks, you'd just change a single pointer. Now
you're pointing to a different state packet, and the state machine
executes the code for the new task.

This worked just fine, and it was even easy to add cheap IO waits and
task priorities. For a while I thought I had a patentable idea,
although it did turn out that I had just reinvented the wheel.

There were two big problems with the idea, though. One was that
long-running operations had to be manually broken up into a sequence
of states. It's just plain easier to write code that makes blocking
calls and acts like it has the whole system to itself. (A related
problem is that setting the state variable is, in effect, a GOTO, and
the compiler can't catch your careless errors. In practice, this
wasn't a very big deal.)

The second big problem was that I implemented my state names as a
Pascal enum. This meant that adding a new state in 'this' file meant I
also had to go to the Globals file and change the enum, and then make
a matching change to the state table. I write the declarations so the
system wouldn't compile if the enum and the state table were out of
synch, but it did make for a lot of fiddling and (when units came
along) a lot of forced recompilation, as everything depended on the
Globals unit.

--

..NET 2.0 for Delphi Programmers
www.midnightbeach.com/.net
What you need to know.
.

Relevant Pages

  • Re: C to Delphi set problems
    ... Somebody else may name these type as TCardsHeldEnum and TCardsHeldSet. ... As mentioned above, your function works on an enum, not on an set. ... element then is as unhandy as is a Delphi set with one member. ...
    (comp.lang.pascal.delphi.misc)
  • Re: accessing the values of underlyingvalue and originalvalue of the changed fields in ADOQuery Will
    ... You would probably want a Delphi example, I can only offer a Builder example ... this and it is a work in progress, hence my own enum of certain ADO ... enum FilterGroupEnum_ {adFilterNone, adFilterPendingRecords, ... if (MessageDlg("The following database changes have been ...
    (borland.public.delphi.database.ado)
  • Re: Whats the big deal with cross-platform?
    ... The Delphi enum should contain the exponents of the 2^b values, the resulting type is a set of that enum. ... Comparisons of signed and unsigned integral types are very common in C, ... In most cases the solution is a signed type for all the unsigned C types, or a subrange that can be sign-extended as required, without further compiler warnings. ...
    (borland.public.delphi.non-technical)
  • Disjoint enumerated types (was: Can someone spot the error here?)
    ... "When specifying such an enumeration type, it is important to keep in mind ... this is a later Delphi extension btw, I've a feeling mostly done because ... enum: EnumType; ...
    (comp.lang.pascal.misc)