OpenEuphoria

Re: RDBMS for DOS and Windows

• Posted by Kat <gertie at ZEBRA.NET> Feb 24, 2000
• 467 views

----- Original Message -----
From: "Brian Jackson" <bjackson at 2FARGON.COM>
To: <EUPHORIA at LISTSERV.MUOHIO.EDU>
Sent: Wednesday, February 23, 2000 11:34 PM
Subject: Re: RDBMS for DOS and Windows

<snip>

> Well I realize that this doesn't help the DOS users out any, but Fabio
> Ramirez has created an SQL wrapper that works really well.  I just started
> learning SQL last week, and I'm already writing data entry programs using
> joined tables, primary and foreign indecies, and all that good stuff.  It
> really has a lot of promise for the WIN32/Linux platform.  DOS
> unfortunately is another story.  I don't forsee anyone coming up with a
> RDBMS library for DOS now or ever, simply due to the fact that the 16-bit
> OS is going the way of the dinosaur.  [Moment of silence].
>

/me hangs her head in shame as she realises that she too is planning to
replace dos on the other puter soonish. Btw, i blame Eu for that, from what
little i have learned, it's the apps that cause windoze fits, and windoze is
usually responcible only for the screen-door security problems,, so if i
write the apps i use, or screen the store-bought apps rigorously, things
should be ok.... unless i can get a good reply to the following that
convinces me i am right about the 16bit comments below....

Something i never understood about 16bit OSs used on a 32bit cpu... since
the cpu fetches 32 bits, it has fetched two instructions at once, and so has
the next instruction already in the cpu's instruction decoder stream,, and
so it should zip thru instructions faster, yeas? Plus the 16 bits can still
use various methods to access 32/64bit memory locations and data locations,
the cpu and hardware is still 32+bit wide, so there isn't a performance hit
there. So why aren't the 16bit OSs being suggested for blazing speed on the
32/64bit cpu families? It seems to me that with the new 128bit paths to a
64bit core, a 16bit OS can execute 2x or more as fast as the code *made for*
those wider cpus, cause it will be capable of dragging 2+ complete operands
and data in one clock cycle. Right?

Kat,
curious as,
but puzzled still.