Thanks for the reply and  considering my input.  You offer good points to
consider.

I remember a DOS task switcher called Doors back in the day of BBS freeware
distribution.  Never got around to trying it out.

I also had a career as a commercial artist and photographer back in the
1980s.  Still do a lot privately.  Some of my graphics files are nearing 2
gigs now.  (I do weird high res stuff.)  The best hardware is just
beginning to approach the information density of good old fashioned 35 mm
film.  Its a printer's eye thing most lay people wouldn't appreciate.  I
think you can see how slicing up an image into more than one file would be
problematic.

CB


On Mon, May 6, 2013 at 10:57 AM, Rugxulo <rugx...@gmail.com> wrote:

> Hi, sorry for late reply,
>
> On Thu, Apr 25, 2013 at 7:46 PM, Charles Belhumeur
> <chbelhumeur2...@gmail.com> wrote:
> >
> > Thanks for the reply.  Glad some of you see things in a way similar to I.
> > Remember the OS on the Amstrad Family Computer.  I guess that's what I'd
> > like to see for a user interface for FreeDos.  Perhaps a little more
> grown
> > up for modern Intel boxes.  It was a small tidy GUI style OS.
>
> Would GEM (aka, OpenGEM) suffice? That's a good as a GUI as we've
> presently got in FreeDOS.
>
> > Task
> > switching but not multi-tasking.  Not a lot of code or effort to create
> that
> > OS by modern standards.  Although I think some of the features were in
> the
> > firmware on that box.  Brings back the remark one of you made about roll
> > your own BIOS.
>
> Not sure how easy task switching would be. (Usually such a thing is
> associated with 286s.) Sure, it can be done (a la MS' DOSSHELL), but
> I'm not sure how feasible it is in FreeDOS stuff without some fancy
> work. Probably easier to use coroutines (or similar) in specific apps
> to simulate the same thing.
>
> There apparently was a GEM/XM (buggy, unfinished) beta (eventually
> GPL'd) for DOS that did task switching, but it wasn't ever finalized.
> Honestly, I'm out of the loop, but I don't know of anyone maintaining
> (any parts of) GEM anymore. At least I can't seem to find Shane's
> homepage(s) online anymore.
>
> > Ah its all coming back to me now.  The Adam Home Computer, the Commodore
> > 6060 (BASIC OS like the HP Workstations).  Man I spent a lot of my life
> > wrestling with flaky boxes and compilers.  Hard to believe I got any
> other
> > work done at the various jobs I've worked at.  Don't have a lot of
> patience
> > left for flaky overcomplicated overreaching OSs and apps.
>
> I don't know. Most Linux developers seem to rely on X11. FreeBSD at
> least comes without X pre-installed. But I'm not sure how much
> graphical stuff you can do without X11, outside of DOS + VESA,
> naturally. (Svgalib isn't very popular these days, and Linux
> framebuffer ... I'm out of the loop, so no idea.)
>
> > Could the leftover RAM on a modern box be used for a disk cache or
> virtual
> > drive?  FreeDos can do this right.  I used to create a virtual drive and
> > then copy my menu app binaries and directory to it at boot.
>  Significantly
> > improved performance with a disk cache as well on my old 12 MHz 286.
>
> I don't know of any decent 286 disk caches for FreeDOS, but yes, many
> of us use things like Jack's (386+) UIDE for UDMA and disk caching, as
> well as a RAM driver for (faster reading/writing of) temporary files.
> Yes, even on modern overpowered machines, it can speed things up a
> lot.
>
> > Just an example of how unused RAM can be used creatively to improve
> performance.
> > There's likely more.  Could you write a ghost BIOS, copy it to RAM and
> then
> > redirect BIOS calls to it?  Maybe not all the BIOS calls, just the
> required
> > ones. Writing BIOSs used to a bit of voodoo and a black art dealing with
> > hardware timing and such.
>
> Not a lot of people want to write their own BIOSes. I don't (and
> couldn't if I tried). So I think that option is probably unlikely to
> be practical, though indeed a very few have tried and succeeded (in
> limited form) over the years, e.g. monahan dude, SeaBIOS, Coreboot, or
> whatever.
>
> > Oh wait before I go, there's good reasons you can't divy up gene sequence
> > files into smaller chunks.  Each segment would need header with even more
> > info than the original header.  Bioinformatics is kind of messed up now
> with
> > all the wankers focused on the IT and not the biology.  All kinds of
> > needless screwing with file formats, file structures, compression and so
> on.
> > (Some wanker got into the game way way way back in the day and we've been
> > stuck with that Big Endian Small Endian crap ever since.)
>
> I refuse to believe you couldn't live with 2 GB files.   :-)     But
> what do I know. Just use whatever works, whatever's at hand. I don't
> expect FreeDOS to cover everyone's need, but it's quite good at what
> it does (and then some, thanks to some very cool developers and
> volunteers).
>
>
> ------------------------------------------------------------------------------
> Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
> Get 100% visibility into your production application - at no cost.
> Code-level diagnostics for performance bottlenecks with <2% overhead
> Download for free and get started troubleshooting in minutes.
> http://p.sf.net/sfu/appdyn_d2d_ap1
> _______________________________________________
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel
>
------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and 
their applications. This 200-page book is written by three acclaimed 
leaders in the field. The early access version is available now. 
Download your free book today! http://p.sf.net/sfu/neotech_d2d_may
_______________________________________________
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Reply via email to