On Mon, Aug 4, 2014 at 10:03 AM, Zbigniew <zbigniew2...@gmail.com> wrote:
> Switching among many startup configurations is something we can't
> avoid in DOS.

I assume you mean CONFIG.SYS menus. The old old days where you needed
to rename / copy separate files in order to multi-boot such setups is
long gone. (Of course, FreeDOS isn't quite MS or DR compatible here,
but who cares?)

Though it's hard to organize such things effectively. It's almost an
art to keep things minimal, isolated, self-contained ... hence it's
actually almost easier to just have separate configs in separate
files. I have three main setups (sets of config files): one for RUFUS
(USB), one for (not quite) "raw", and my main desktop's (menu-based,
which I rarely use) setup. I don't know if it would be wise to merge
them all. Heck, I don't even reliably have them backed up. Maybe we
need a public Git repo or such for popular end user CONFIG + AUTOEXEC
files, for example, to help people when setting things up. I have a
(very) few examples from years ago, but I never use them.

In other words, maybe I'm overthinking it (again), but there's always
room for improvement. Obviously if you don't want to have to reboot a
lot, keep things separate where you can DEVLOAD drivers (only when
needed) or unload TSRs (thus keep all of those at the end, where they
won't clash with others). Like I've mentioned before, I don't use
JEMM386 at all by default, so if I need it, I just "LOAD" it at
runtime (and "UNLOAD" when done), thus saving me the (minor)
compatibility hassle. Also, my last three TSRs can unload, e.g.
CTMOUSE, NNANSI, SHCDX33F ... if I was desperate for more than 600 kb
of conventional memory (unlikely).

> I was pondering one day, whether could be possible to
> "reset" DOS without resetting entire machine... it would make such
> switch much faster. Just some kind of "full system reload" - similar
> way as LOADLIN does it - when switching from DOS to Linux without
> reset.

Booting up is already very fast, compared to every other OS. In fact,
I think my (Lenovo) BIOS has some kind of switch that boots up
slightly faster (can't remember, probably just smaller delay to hit
F12 or whatever for General Setup or Select Boot Media).

And here's the real reason I'm replying to this email:  JEMM's
"FASTBOOT". It seems this was first implemented back in 2007.  See
README.TXT's "Other Tools" (6.2).


 JEMFBHLP is a tiny device driver only needed if both FreeDOS and Jemm's
 FASTBOOT option are used. FreeDOS v1.0 does not provide the information
 that Jemm needs for FASTBOOT to work, so this driver tries to cure FreeDOS'
 incapability. It saves the values for interrupt vectors 15h and 19h at
 0070h:0100h, which is the MS-DOS compatible way to do it.

 I was told that in FreeDOS v1.1 this problem has been fixed.

Honestly, I never use this. It wasn't that crucial. I don't know how
well it works, how bug-free it is. I vaguely think I did enable it way
back on my RUFFIDEA disk #3, but again, I don't actively use that

If anybody knows whether the helper tool is still needed (in FD 1.1),
feel free to tell us. Yeah yeah, I could reboot and "see what happens"
(crash!), but that doesn't interest me ... much. So no promises, test
it yourself!   :-P    :-)

N.B. It warns that (in addition to JEMFBHLP) you may have to set
"STACKS=0,0" and not move the XBDA.

Infragistics Professional
Build stunning WinForms apps today!
Reboot your WinForms applications with our WinForms controls. 
Build a bridge from your legacy apps to the future.
Freedos-user mailing list

Reply via email to