DOS ain't dead

I'm considering using MS-DOS on a 'modern' computer (dual-booting with XP or Windows 7) and I have a few queries.

(1) should I use MS-DOS 6.22/MS-DOS 7.1 or one of the compatible OSs e.g. FreeDOS, and if so why?

(2) given that I'll be running DOS on a PC with 3 or 4 GB of RAM, I presume DOS won't cough at this i.e. DOS will just 'see' 640k conventional RAM or up to 16MB EMS/XMS?

(3) would I be better using FAT16 or FAT32 filing system? If FAT32 am I right in assuming I'd need MS-DOS 7.1 (or FreeDOS)?

(4) are the utilities in FreeDOS e.g. JEMM386, 'better' than their MS-DOS equivalents?

(5) what other utilities (not included in MS-DOS or FreeDOS) do the experts on this forum recommend?

TIA

Paul
Melbourne, Australia

> (4) are the utilities in FreeDOS e.g. JEMM386, 'better' than their MS-DOS
> equivalents?

The quality of the FreeDOS utilities varies from "unusable" to "excellent", so one cannot say much in general.

JEMM386, of course, is better, in both ethical and technical aspect of this attribute.

---
MS-DOS forever!

Hi,

> I'm considering using MS-DOS on a 'modern' computer (dual-booting with XP
> or Windows 7) and I have a few queries.
>
> (1) should I use MS-DOS 6.22/MS-DOS 7.1 or one of the compatible OSs e.g.
> FreeDOS, and if so why?

Depends on if you have a license and what you want to do. 6.22 is old standard but (IIRC) lacks LBA and FAT32 (which 7.x has). If you want to run really old stuff like Win3x or Desqview, you're much better off running true MS-DOS or DR-DOS. However, you could also run ROM-DOS 7 (LFNs) or EDR-DOS (both support FAT32, free for personal use). And DR-DOS 7.03 ($35 US) supports multitasking (max 64 MB per task) but no FAT32 nor LFN. Oops, almost forgot PTS-DOS 32 (shareware) may support FAT32. PC-DOS 7.1 (eh?) in IBM Server Scripting Toolkit may?? be "freeware" nowadays and supposedly now has FAT32 support.

Really, the main advantage to FreeDOS is still being (barely) supported, open source aka free/libre, and lets you tinker ad nauseum. It's not perfect but fairly close. It does support LBA, FAT32, optional LFN (w/ driver).

Actually, you don't have to choose, you can use MetaKern or BootMGR (or ...) to multi-boot between DOSes. But if you don't have any particular preference, I think FreeDOS is a safe bet. (And you can join the mailing lists for free tech support, whee!)

> (2) given that I'll be running DOS on a PC with 3 or 4 GB of RAM, I presume
> DOS won't cough at this i.e. DOS will just 'see' 640k conventional RAM or
> up to 16MB EMS/XMS?

Amount of EMS or XMS depends on hardware and driver, not DOS per se. With HIMEMX or XMGR (both XMSv3), you should be able to access 2 GB. With HDPMI32 or CWSDPMI r7, you should be able to (maybe??) access 4 GB. I'm not aware of the limits of MS-DOS 6.22 or 7.x's EMM386 or JEMM386, but Japheth or Jack would probably know. (Some old old versions limited to 32 MB. And XMSv2 is limited to 64 MB, but you won't probably have to worry about that.)

> (3) would I be better using FAT16 or FAT32 filing system? If FAT32 am I
> right in assuming I'd need MS-DOS 7.1 (or FreeDOS)?

DR-DOS 7.03 and MS-DOS 6.22 don't support FAT32, nor does traditional PTS-DOS nor ROM-DOS 6 (I think??). It's only important if you need or want more than four primary partitions (where FAT16 maxes out at 2 GB, so 4 x 2 = 8 GB). In theory, also FAT32 supports 4 GB individual files (vs. 2 GB for FAT16), but tools' support for that is problematic, and FreeDOS doesn't (yet) support more than 2 GB per file (sadly).

I'm not exactly sure of the implications of cluster size with FAT16 vs. FAT32. It may depend more on the FDISK tool used. But I always thought (right or wrong) that FAT16 was worse at cluster waste than FAT32. I know that I was always mad that I created a 1 GB FAT16 drive (16 kb clusters) when I should've used two 500 MB ones (4 kb clusters) instead to save space.

> (4) are the utilities in FreeDOS e.g. JEMM386, 'better' than their MS-DOS
> equivalents?

Some (but not all) FreeDOS utils support LFNs (if DOSLFN or similar loaded), unlike MS-DOS. However, some things in MS-DOS don't exist elsewhere or are better (QBASIC, DOSSHELL). Otherwise, FreeDOS is mostly superior, esp. codepages supported.

JEMM386 supports V86 mode "enhanced" (586) for faster speed. It also supports JLMs (via JLOAD). And it's probably less buggy and limited than MS-DOS 6.22's, but you'd have to ask Japheth or Jack for more details. Some (?) people don't load EMM386 at all unless they need it (rare, only for "old" apps using EMS), esp. since modern DOSes give you enough free RAM to not worry about UMBs. And JEMM386 (if no UMBs used) can "LOAD" or "UNLOAD" at will, unlike MS'. Also, it supports "FASTBOOT", which is nice.

> (5) what other utilities (not included in MS-DOS or FreeDOS) do the experts
> on this forum recommend?

I really hate to promote my own crappy site, but it does have a bunch of links and stuff. Or search FreeDOS' iBiblio section (5.5 GB of stuff) or Club DR-DOS wiki.)

> TIA

YW.

> Paul
> Melbourne, Australia

P.S. I'm American, but I did find out recently that I do have a (distant) American (second) cousin living in Melbourne with husband and new baby.

> (1) should I use MS-DOS 6.22/MS-DOS 7.1 or one of the compatible OSs e.g.
> FreeDOS, and if so why?

I recommend FreeDOS or EDR-DOS (I have both in my BOOT-MENU).

> (2) given that I'll be running DOS on a PC with 3 or 4 GB of RAM, I presume
> DOS won't cough at this i.e. DOS will just 'see' 640k conventional RAM

DOS will see just 640 KiB, right.

> up to 16MB EMS/XMS?

Up to 2 GiB or 4 GiB (- PCI MMIO space) RAM as XMS and for good DOS extenders.

> (3) would I be better using FAT16 or FAT32 filing system?

| > 2 GiB FAT28 is necessary
| 1/2 GiB to 2 GiB depends
| < 1/2 GiB use FAT16

> (5) what other utilities (not included in MS-DOS or FreeDOS) do the
> experts on this forum recommend?

See answer above.

> The quality of the FreeDOS utilities varies from "unusable" to "excellent",
> so one cannot say much in general.

Right There is no good SCANDISK or DEFRAG for example.

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

> I'm considering using MS-DOS on a 'modern' computer (dual-booting with XP
> or Windows 7) and I have a few queries.
>
> (1) should I use MS-DOS 6.22/MS-DOS 7.1 or one of the compatible OSs e.g.
> FreeDOS, and if so why?

How modern? The first problem you'll encounter is whether a 64 bit system will run a 16 bit OS. I've seen discussions elsewhere from folks losing legacy MS-DOS applications when moving to a 64 bit box because they don't run under Win7 unless you use a virtual machine setup.

> (2) given that I'll be running DOS on a PC with 3 or 4 GB of RAM, I presume
> DOS won't cough at this i.e. DOS will just 'see' 640k conventional RAM or
> up to 16MB EMS/XMS?

It sees 640K conventional, and 16MB XMS.

I triple boot Win2K Pro, WinXP Pro, and Ubuntu 11.04 on a 2.6 CoreDuo box with 4GB RAM. 32 bit Windows can't use all 4GB for architectural reasons - it can only use about 3.2GB - but I founds a freeware ramdisk driver that can use the extra memory, so I have a 763MB ramdisk seen as a compressed NTFS volume called Z: by Windows. I run Firefox from it, and put the profile there too. Quick...

XP will run MS-DOS apps in a sandbox provided by NTVDM, which implements a virtual MS-DOS 5.0 environment. When I'm in the virtual DOS environment, I see this, using 4DOS as my command processor::

[0]4DOS> mem /c

Conventional Memory :

Name Size in Decimal Size in Hex
------------- --------------------- -------------
MSDOS 12368 ( 12.1K) 3050
KBD 3296 ( 3.2K) CE0
HIMEM 1248 ( 1.2K) 4E0
ANSIPLUS 6656 ( 6.5K) 1A00
COMMAND 4768 ( 4.7K) 12A0
DOSX 34720 ( 33.9K) 87A0
4DOS 283312 (276.7K) 452B0
FREE 112 ( 0.1K) 70
FREE 308640 (301.4K) 4B5A0

Total FREE : 308752 (301.5K)

Upper Memory :

Name Size in Decimal Size in Hex
------------- --------------------- -------------
SYSTEM 192496 (188.0K) 2EFF0
DOSX 128 ( 0.1K) 80
4DOS 3104 ( 3.0K) C20
MOUSE 12528 ( 12.2K) 30F0
MSCDEXNT 464 ( 0.5K) 1D0
REDIR 2672 ( 2.6K) A70
CmdEdit 10272 ( 10.0K) 2820
FREE 1952 ( 1.9K) 7A0
FREE 38368 ( 37.5K) 95E0

Total FREE : 40320 ( 39.4K)

Total bytes available to programs (Conventional+Upper) : 349072 (340.9K)
Largest executable program size : 306544 (299.4K)
Largest available upper memory block : 38368 ( 37.5K)

15728640 bytes total contiguous extended memory
0 bytes available contiguous extended memory
15547392 bytes available XMS memory
MS-DOS resident in High Memory Area

XP uses the files AUTOEXEC.NT and CONFIG.NT in Windows\System32 to initialize DOS sessions, and anything specified in them is applied to any DOS session you run. I do this:

CONFIG.NT:

dos=high, umb
files=40
device=%SystemRoot%\system32\himem.sys
device=d:\console\ansiplus\ansiplus.exe /h

I'm loading Kristopher Sweger's old shareware ANSIPlus ANSI driver high. It's freeware now, and available here: http://www.sweger.com/ansiplus/

AUTOEXEC.NT:

@echo off
:: AUTOEXEC.BAT is not used to initialize the MS-DOS environment.
:: AUTOEXEC.NT is used to initialize the MS-DOS environment unless a
:: different startup file is specified in an application's PIF.

:: Install CD ROM extensions
lh %SystemRoot%\system32\mscdexnt.exe
:: Install network redirector (load before dosx.exe)
lh %SystemRoot%\system32\redir
:: Install DPMI support
lh %SystemRoot%\system32\dosx

:: Install enhanced command line editor
lh d:\Console\DOS\cmdedit.com -qcikp" " /h1024 /s1024 /m512 /ah256 d:\Console\DOS\cmdedit.cfg

setaplus keyfile d:\Console\DOS\keydef.cfg tone 1397,110,1047,165
setaplus enable ctrlc ndlast capsun capsre smooth speedup winsmooth scroll32bit clsback
kscolors

path d:\console\4dos;c:\mingw\msys\1.0\bin;c:\mingw\bin;d:\windows\system32;
d:\windows;d:\windows\system32\wbem;d:\console\dos\;d:\console\dos\batch;
d:\program files\gnuwin32\bin;d:\console\usr\local\wbin;d:\console\bin

set BLASTER=A220 I5 D1 P330 T3
set TMP=z:\tmp
set temp=z:\Temp
set TZ=EST8EDT
cls
echo Windows XP command shell on %computername%

The entries that load mscdexnt, redir, and dosx are the default. IF you decide you don't need those capabilities, you can remove them or comment them out to get more DOS conventional memory. (They can be loaded in an application batch file if an app does need them.)

I load an old PC Magazine command line editor called CMDEDIT, in an enhanced version from Jason Hood. I normally run 4DOS as my command processor, which has built-in command line editing. CMDEDIT is there for the benefit of applications like Vern Buerg's old LIST and MS-DOS debug, which use DOS function 0AH to get keyboard input. A TSR command editor is active within them as well as at the command line in places where user input can be given.

I also specify the PATH I want DOS apps to see, and run a utility that does ANSIPlus setup.

I do *not* specify the prompt. CONFIG.NT and AUTOEXEC.NT are processed *every* time a copy of COMMAND.COM is spawned in an NTVDM. I prefer to use application specific prompts, set in the batch file that runs them (so I have some reminder of which app I'm shelled out of if I shell to DOS), and defining the prompts in AUTOEXEC,NT will reset it to whatever is defined there when I shell.

An important note on the NTVDM sandbox: 16 bit DOS apps run in it, and if you shell out of one a copy of COMMAND.COM is spawned, but whenever you run an external program, it gets passed back to CMD.EXE to process. Only DOS apps are trapped in the sandbox, and you can execute 32 bit Windows programs when shelled out of a DOS app.

For instance, I run Eric Meyer's MS-DOS VDE word processor. VDE lets you shell out by pressing AltR. AltR produces a prompt line. If you just press Enter, you'll be in a sub-shell with whatever COMSPEC points to. If you specify something on the VDE AltR line, you'll get whatever it is.

So I can do AltR cmd /c start /shared 4DOS.com to spawn a copy of 4DOS in a separate window, inheriting the VDE environment. I can spawn anything in a separate window this way, including a Windows GUI app.

> (3) would I be better using FAT16 or FAT32 filing system? If FAT32 am I
> right in assuming I'd need MS-DOS 7.1 (or FreeDOS)?

I have FreeDOS 1.0 quad-booting on an old notebook with Win2K and two flavors of Linux. FreeDOS is on a FAT32 partition, and works fine. (Getting FreeDOS to boot from Grub required fiddling, and I don't recall exactly which* fiddle made it work )

FAT16 has a 2GB limit on volume size, so if you want to use a larger partition for DOS, you'll need FAT32.

> (4) are the utilities in FreeDOS e.g. JEMM386, 'better' than their MS-DOS
> equivalents?

At least equivalent.

> (5) what other utilities (not included in MS-DOS or FreeDOS) do the experts
> on this forum recommend?

Substitute 4DOS for command.com. 4DOS was JPSoftware's shareware drop in COMMAND.COM replacement. It added command line history, recall, and editing, command aliases, a full screen file viewer ala LIST, a vastly enhanced batch language, and an assortment of other features. 4DOS author Rex Conn released it as open source when MS-DOS was no longer used enough to justify continued support and enhancement, and now offers a shareware 32 bit Windows offering called Take Command instead. A Bulgarian developer picked it up, and the current 8.0 version is here: http://4dos.isgreat.org/

(A freeware console version of Take Command called TCC/LE is available, and I have it here. The stuff the Limited Edition omits is mostly stuff I don't need. But it's based on 4DOS code, and uses the same config files, so I have the same 4DOS features in a 32 bit Windows console.

See http://jpsoft.com/tccle_cmd_replacement.html )

Other things I'm fond of include:

ListPlus: The late Vern Buerg's fill screen file browser utility. The last version includes Long File Name support if you run a DOS extender that provides it. Look here: ftp://garbo.uwasa.fi/pc/fileutil/listp96x.zip

It was no-nag shareware back in the day, and all functions work properly, even though it can no longer be registered.

Directory Freedom: Gordon Haff's DOS file manager utility, based on a PC Magazine utility by Michael Mefford. DF is highly configurable, and will let you customize what actions are taken on files based on the file extension, so you can add custom viewers for handling various file types.

Look here: http://home.comcast.net/~ghaff/bitmason/dflyer.html

T: Editor for DOS and OS/2, written by Tim Baldwin at IBM's UK labs. The design resembles the old IBM Personal Editor. The DOS version weighs in at 9KB. I keep it on a ramdisk for instant use.

Look here: http://hobbes.nmsu.edu/download/pub/os2/apps/editors/tinyed.zip

VDE: Eric Meyer's MS-DOS word processor, using the WordStar command set. It began as an alternative to WordStar under CP/M, and was later ported to DOS. It's freeware these days, and Eric still maintains it. There was a 1.96a release in November 2009.

Look here: https://sites.google.com/site/vdeeditor/

There are others but that's a start.

> TIA

> Paul
> Melbourne, Australia
______
Dennis

> T: Editor for DOS and OS/2, written by Tim Baldwin at IBM's UK labs. The
> design resembles the old IBM Personal Editor. The DOS version weighs in at
> 9KB. I keep it on a ramdisk for instant use.
>
> Look here: http://hobbes.nmsu.edu/download/pub/os2/apps/editors/tinyed.zip

That's version 2.20a. 2.20b is here: http://www.tavi.co.uk/os2pages/ews.html

---
Forum admin

> VDE: Eric Meyer's MS-DOS word processor, using the WordStar command set.
> It began as an alternative to WordStar under CP/M, and was later ported to
> DOS. It's freeware these days, and Eric still maintains it. There was a
> 1.96a release in November 2009.
>
> Look here: https://sites.google.com/site/vdeeditor/

At https://sites.google.com/site/vdeeditor/Home/vde-files you write "Halibut by the Gnu Project". That's wrong. Halibut is a project by Simon Tatham under MIT license.

---
Forum admin

> > VDE: Eric Meyer's MS-DOS word processor, using the WordStar command set.
>
> > It began as an alternative to WordStar under CP/M, and was later ported
> to
> > DOS. It's freeware these days, and Eric still maintains it. There was
> a
> > 1.96a release in November 2009.
> >
> > Look here: https://sites.google.com/site/vdeeditor/
>
> At https://sites.google.com/site/vdeeditor/Home/vde-files you write
> "Halibut by the Gnu Project". That's wrong. Halibut is a project by Simon
> Tatham under MIT license.

Fixed. Thank you.
______
Dennis

> > T: Editor for DOS and OS/2, written by Tim Baldwin at IBM's UK labs. The
> > design resembles the old IBM Personal Editor. The DOS version weighs in
> at
> > 9KB. I keep it on a ramdisk for instant use.
> >
> > Look here:
> http://hobbes.nmsu.edu/download/pub/os2/apps/editors/tinyed.zip
>
> That's version 2.20a. 2.20b is here:
> http://www.tavi.co.uk/os2pages/ews.html

Thank you. I've updated the Download link of the TextEditors wiki to point to it.
______
Dennis

> The quality of the FreeDOS utilities varies from "unusable" to "excellent",
> so one cannot say much in general.
>
> JEMM386, of course, is better, in both ethical and technical aspect of this
> attribute.

Japheth: reading the description on your website for JEMM386 would certainly seem to support your contention

Rugxulo: thanks for your amazingly comprehensive answer (snipped to avoid cluttering up this post) - you have certainly given me a thorough summary of options which I will investigate. And I will look at your website.


Funnily enough, I recently met up with a cousin of mine here in Melbourne who I'd not seen since the mid-60s.

DOS386: thanks for the suggestions. There certainly seems to be no lack of options.

Dennis: thanks for your very full answer.

Regarding your comments about the XP NTVDM environment, my understanding is that it is a less than full emulation of MS-DOS. For example if I run Javelin (an old DOS time series/financial modelling package) in XP's NTVDM, it doesn't 'see' any EMS. If I run it in DOSBOX, Javelin 'sees' 16MB of additional memory (over and above conventional memory.)

I have considered MS-DOS in a virtual environment - Virtual PC, Virtual Box and VMWare Player - all of which work fine. The main problem is that you cannot run MS-DOS in such environments in full-screen mode. You just get a small 'window' containing the MS-DOS screen and, if you hit Alt-Enter, all that happens is the window stays the same size and the remaining screen space becomes a black boundary. The suggestion I've seen elsewhere of changing the host screen size (to the equivalent of a 80x25 VGA-type screen ) doesn't really appeal!

> Dennis; thanks for your very full answer.

You're welcome.

One concern I don't have a clear feeling for is whether you'll be able to multi-boot DOS. A poster elsewhere was in high dudgeon because he bought a new Dell PC and discovered they'd removed the ability to boot MS-DOS from the BIOS. He returned it and is looking elsewhere. I'm less upset. Current machines are all 64bit boxes, and many current computer users weren't born or were toddlers when DOS was in regular use. The vast majority of users will have no need to boot to DOS, let alone run DOS apps, and won't miss the capability.

> Regarding your comments about the XP NTVDM environment, my understanding is
> that it is a less than full emulation of MS-DOS. For example if I run
> Javelin (an old DOS time series/financial modelling package) in XP's NTVDM,
> it doesn't 'see' any EMS. If I run it in DOSBOX, Javelin 'sees' 16MB of
> EMS.

Play with the values in CONFIG.NT. I don't need EMS, and don't care, but it appears to be possible to configure it.

I didn't post the full text of my CONFIG.NT file. The part left out was

:: EMM
:: You can use EMM command line to configure EMM(Expanded Memory Manager).
:: The syntax is:
::
:: EMM = [A=AltRegSets] [B=BaseSegment] [RAM]
::
:: AltRegSets
:: specifies the total Alternative Mapping Register Sets you
:: want the system to support. 1 <= AltRegSets <= 255. The
:: default value is 8.
:: BaseSegment
:: specifies the starting segment address in the Dos conventional
:: memory you want the system to allocate for EMM page frames.
:: The value must be given in Hexdecimal.
:: 0x1000 <= BaseSegment <= 0x4000. The value is rounded down to
:: 16KB boundary. The default value is 0x4000
:: RAM
:: specifies that the system should only allocate 64Kb address
:: space from the Upper Memory Block(UMB) area for EMM page frames
:: and leave the rests(if available) to be used by DOS to support
:: loadhigh and devicehigh commands. The system, by default, would
:: allocate all possible and available UMB for page frames.
::
:: The EMM size is determined by pif file(either the one associated
:: with your application or _default.pif). If the size from PIF file
:: is zero, EMM will be disabled and the EMM line will be ignored.

I have DOSBox under Linux and it works fine. My big complaint is that DOSBox is intended for running old MS-DOS games, and thinks of screen sizes in terms of graphics resolution. As a result, it appears limited in character mode to 80x25 screen sizes. I want 80x50 VGA mode, or at least 80x43 EGA mode if I can't get 80x50.

> I have considered MS-DOS in a virtual environment - Virtual PC, Virtual Box
> and VMWare Player - all of which work fine. The main problem is that you
> cannot run MS-DOS in such environments in full-screen mode. You just get a
> small 'window' containing the MS-DOS screen and, if you hit Alt-Enter, all
> that happens is the window stays the same size and the remaining screen
> space becomes a black boundary. The suggestion I've seen elsewhere of
> changing the host screen size (to the equivalent of a 80x25 screen) doesn't
> really appeal!

Er, why do you want to run DOS full screen? I prefer large monitors with lots of screen real estate, and the last thing I want is a DOS app filling the entire screen. I want DOS apps in a window.

In your position, I'd look at a VM solution, rather than trying to multi-boot.
______
Dennis

> > Dennis; thanks for your very full answer.
>
> You're welcome.
>
> One concern I don't have a clear feeling for is whether you'll be
> able to multi-boot DOS. A poster elsewhere was in high dudgeon
> because he bought a new Dell PC and discovered they'd removed the ability
> to boot MS-DOS from the BIOS. He returned it and is looking elsewhere.
> I'm less upset. Current machines are all 64bit boxes, and many current
> computer users weren't born or were toddlers when DOS was in regular use.
> The vast majority of users will have no need to boot to DOS, let alone run
> DOS apps, and won't miss the capability.

I'm beginning to think I don't want the complications of dual booting. I have an old desktop PC whose main hard drive has failed. I'm thinking of putting in a new HDD or swapping over the secondary hard drive and using this as a dedicated MS-DOS machine. I might as well use this PC since it's not doing anything at the moment.

> Play with the values in CONFIG.NT. I don't need EMS, and don't care, but
> it appears to be possible to configure it.

I have seen that but I'm not sure I understand it

> I have DOSBox under Linux and it works fine. My big complaint is that
> DOSBox is intended for running old MS-DOS games, and thinks of
> screen sizes in terms of graphics resolution. As a result, it appears
> limited in character mode to 80x25 screen sizes. I want 80x50 VGA mode, or
> at least 80x43 EGA mode if I can't get 80x50.

You might find the first post here http://vogons.zetafleet.com/viewtopic.php?t=22617&start=19 useful and especially the file link (TEXTUTIL.ZIP). I have used 80X50.COM in a custom JAVELIN.CONF DOSBOX config file to boot Javelin straight into 80 X 50 mode.

> Er, why do you want to run DOS full screen? I prefer large monitors with
> lots of screen real estate, and the last thing I want is a DOS app filling
> the entire screen. I want DOS apps in a window.

I just find the DOS 'window' too small, especially on a laptop screen

> In your position, I'd look at a VM solution, rather than trying to
> multi-boot.

See my first comment in this post.

Thanks again.

> I'm beginning to think I don't want the complications of dual booting.

I forgot to mention that most DOSes (esp. MS-DOS) are pretty limited about where you can install them. Even DR-DOS is not perfect, though better. At least in this area, it's very clear that FreeDOS works best. But long story short, install MS-DOS (or others) first, then FreeDOS.

> > Play with the values in CONFIG.NT. I don't need EMS, and don't care,
> but
> > it appears to be possible to configure it.
>
> I have seen that but I'm not sure I understand it

For "personal, non-commercial use", you can try EMS Magic, in Windows or DOS (TSR that doesn't interfere with anything).

> > I have DOSBox under Linux and it works fine. My big complaint is that
> > DOSBox is intended for running old MS-DOS games, and thinks of
> > screen sizes in terms of graphics resolution. As a result, it appears
> > limited in character mode to 80x25 screen sizes. I want 80x50 VGA mode, or
> > at least 80x43 EGA mode if I can't get 80x50.
>
> You might find the first post here > http://vogons.zetafleet.com/viewtopic.php?t=22617&start=19 useful and > especially the file link (TEXTUTIL.ZIP). I have used 80X50.COM in a custom > JAVELIN.CONF DOSBOX config file to boot Javelin straight into 80 X 50 mode.

80x50? FreeDOS mode supports it, and I've seen ASM code to do similar in a handful of lines.

EDIT: (I'm kinda assuming here that you have DEBUG installed, heh. And yes, it works in DOSBox!)


; thanks to Loren Blaney
org 100h
mov ax,1202h
mov bx,30h
int 10h
mov ax,3
int 10h
mov ax,1112h
xor bx,bx
int 10h
int 20h


> I'm beginning to think I don't want the complications of dual booting. I
> have an old desktop PC whose main hard drive has failed. I'm thinking of
> putting in a new HDD or swapping over the secondary hard drive and using
> this as a dedicated MS-DOS machine. I might as well use this PC since it's
> not doing anything at the moment.

Dual-booting isn't all that complicated, depending upon what you're booting. The question is whether it's the best way to accomplish what you want to do. In the case of running the odd MS-DOS application, I'd say no - go with one or another VM setup.

If you just want a retro toy to play with, it may be another matter, but that may be better done on a different machine.

> > Play with the values in CONFIG.NT. I don't need EMS, and don't care,
> > but it appears to be possible to configure it.
>
> I have seen that but I'm not sure I understand it

I'm not sure I do either, save that it indicates EMS is supported. As mentioned, I don't require EMS for anything and haven't had cause to fiddle with it.

> > I have DOSBox under Linux and it works fine. My big complaint is that
> > DOSBox is intended for running old MS-DOS games, and thinks of
> > screen sizes in terms of graphics resolution. As a result, it appears
> > limited in character mode to 80x25 screen sizes. I want 80x50 VGA mode,
> > or at least 80x43 EGA mode if I can't get 80x50.
>
> You might find the first post here
> http://vogons.zetafleet.com/viewtopic.php?t=22617&start=19 useful and
> especially the file link (TEXTUTIL.ZIP). I have used 80X50.COM in a custom
> JAVELIN.CONF DOSBOX config file to boot Javelin straight into 80 X 50
> mode.

Thank you! The included 80x50.com does the trick.

> > Er, why do you want to run DOS full screen? I prefer large monitors
> > with lots of screen real estate, and the last thing I want is a DOS app
> > filling the entire screen. I want DOS apps in a window.
>
> I just find the DOS 'window' too small, especially on a laptop screen

On a laptop, maybe. My old notebook does 1280x768. and there I run FreeDOS full screen. My desktop has a larger screen, and DOS full screen is a bit too much of a good thing.

The SO's 64 bit laptop is a "widescreen" model, and I'd want character mode apps in a window there, too.

> > In your position, I'd look at a VM solution, rather than trying to
> > multi-boot.
>
> See my first comment in this post.

If you have what has become a spare machine with no higher purpose in life, making a straight DOS box of it might be reasonable.

On the old notebook here. FreeDOS is essentially a tech toy to play with. Actual work is done elsewhere. I just enjoy fiddling with it.

> Thanks again.

You're welcome.
______
Dennis

>
> For "personal, non-commercial use", you can try
> EMS Magic, in Windows or DOS (TSR
> that doesn't interfere with anything).

I've tried EMS Magic. As far as Javelin is concerned - because of the way Javelin pages EMS - it didn't work. I had a detailed explanation of this from the author of EMS Magic.

>
> 80x50? FreeDOS mode supports it, and I've seen ASM code to do similar in a
> handful of lines.
>
> EDIT: (I'm kinda assuming here that you have DEBUG installed, heh. And yes,
> it works in DOSBox!)
>
>
> ; thanks to Loren Blaney
> org 100h
> mov ax,1202h
> mov bx,30h
> int 10h
> mov ax,3
> int 10h
> mov ax,1112h
> xor bx,bx
> int 10h
> int 20h
>

ASM? I run a mile when I see that

>
> If you have what has become a spare machine with no higher purpose in life,
> making a straight DOS box of it might be reasonable.
>
Well, I've just turned the PC on and it's completely dead - kaput! Last time I turned it on (a couple of weeks ago) something - the fan? - made a horrible noise for a minute or so before calming down. Now, there's no response whatsoever. So that idea's dead in the water

> So that idea's dead in the water

FWIW, and in case you have another machine to play with, I use MS-DOS 6.20.
I run DOS about 95 % of the time, and Linux the rest.
I multi-boot from a DOS boot menu, to DOS or one of 5 Linux installs.
If I need LFNs, I boot a Linux. Otherwise, DOS does almost everything else,
including maintaining my two domains, sound and video.

Ron, Upper Yarra Valley, VIC, Oz.

---
AUSREG Consultancy http://www.ausreg.com
Tadpole Tunes http://www.tadpoletunes.com
Sna Keo Il http://www.tadpoletunes.com/sna_keo_il/

>
> FWIW, and in case you have another machine to play with, I use MS-DOS
> 6.20.
> I run DOS about 95 % of the time, and Linux the rest.
> I multi-boot from a DOS boot menu, to DOS or one of 5 Linux installs.
> If I need LFNs, I boot a Linux. Otherwise, DOS does almost everything
> else,
> including maintaining my two domains, sound and video.
>

Ron: my daughter has a laptop she doesn't use (she's on the iPhone all the time!) so I might buy that off her and use that... but a 300GB hard drive will have a lot of unused space unless I dual boot.

---
Paul
Melbourne, Australia

> Ron: my daughter has a laptop she doesn't use (she's on the iPhone all the
> time!) so I might buy that off her and use that... but a 300GB hard drive
> will have a lot of unused space unless I dual boot.

It is easy enough to create enough partitions from 300 GB, if you would like
to include an extended DOS partition containing logical drives, as well as a
large partition for a Linux - even at a later stage.

e.g. On my main machine (2 x HDD), I have 4 FAT16 DOS partitions (2 GB each)
and 4 Linux ext2 partitions (including one of 32 GB), and I can boot any of
those from the DOS boot menu using .bat files.

---
AUSREG Consultancy http://www.ausreg.com
Tadpole Tunes http://www.tadpoletunes.com
Sna Keo Il http://www.tadpoletunes.com/sna_keo_il/

>
> It is easy enough to create enough partitions from 300 GB, if you would
> like
> to include an extended DOS partition containing logical drives, as well as
> a
> large partition for a Linux - even at a later stage.
>
> e.g. On my main machine (2 x HDD), I have 4 FAT16 DOS partitions (2 GB
> each)
> and 4 Linux ext2 partitions (including one of 32 GB), and I can boot any of
>
> those from the DOS boot menu using .bat files.

Ron: my problem is that I'm not sure how to go about partitioning a hard disk in that way.

---
Paul
Melbourne, Australia

> > It is easy enough to create enough partitions from 300 GB, if you would
> > like to include an extended DOS partition containing logical drives, as
> > well as a large partition for a Linux - even at a later stage.
> >
> > e.g. On my main machine (2 x HDD), I have 4 FAT16 DOS partitions (2 GB
> > each) and 4 Linux ext2 partitions (including one of 32 GB), and I can boot
> > any of those from the DOS boot menu using .bat files.
>
> Ron: my problem is that I'm not sure how to go about partitioning a hard
> disk in that way.

I tend to use Linux GPartEd, the Gnome Partition Editor, for that. It's a graphical partition manager that lets you create, manipulate, and delete partitions, and format the partitions to the desired filesystem.

You can get it as an ISO intended to be burned to a CD you can boot from. The CD boots a Linux kernel and runs GPartEd, so you can use it to partition arbitrary machines, as long as the box supports booting from CD.

See http://gparted.sourceforge.net/
______
Dennis

> > > Er, why do you want to run DOS full screen? I prefer large monitors
> > > with lots of screen real estate, and the last thing I want is a DOS app
> > > filling the entire screen. I want DOS apps in a window.
> >
> > I just find the DOS 'window' too small, especially on a laptop screen

While I think of it, you can adjust the DOS window size by playing with the PIF file for the shortcut that runs the DOS session. You can set things like the preferred screen size, such as 80x50, and you can change the window size by specifying the preferred font to use, instead of defaulting to Auto. The box will be rendered large enough to display the desired rows/columns using the specified font. I generally use the 10x18 font setting as a good default.
______
Dennis

> Ron: my problem is that I'm not sure how to go about partitioning a hard
> disk in that way.

The first (primary) partition should go in during the DOS installation, whichever DOS you choose.
After that, DOS FDISK can create and format the other FAT16 partitions, including any "extended DOS" partitions.

I would advise against using a Linux application to create DOS partitions.
Partitions should be created, and formatted, in the OS they are for: create DOS partitions in DOS, Linux partitions in Linux, otherwise it can mangle the partition tables.

I learned that the hard way !

---
AUSREG Consultancy http://www.ausreg.com
Tadpole Tunes http://www.tadpoletunes.com
Sna Keo Il http://www.tadpoletunes.com/sna_keo_il/

>
> I tend to use Linux GPartEd, the Gnome Partition Editor, for that. It's a
> graphical partition manager that lets you create, manipulate, and delete
> partitions, and format the partitions to the desired filesystem.
>
> You can get it as an ISO intended to be burned to a CD you can boot from.
> The CD boots a Linux kernel and runs GPartEd, so you can use it to
> partition arbitrary machines, as long as the box supports booting from CD.
>
> See http://gparted.sourceforge.net/
> ______
> Dennis

Dennis: I need to update my knowledge on disk partitioning from a 'raw' hard disk, I think. I've used Disk Partitioners to readjust partition sizes on existing XP systems.

---
Paul
Melbourne, Australia

> > Ron: my problem is that I'm not sure how to go about partitioning a hard
> > disk in that way.
>
> The first (primary) partition should go in during the DOS installation,
> whichever DOS you choose.
> After that, DOS FDISK can create and format the other FAT16 partitions,
> including any "extended DOS" partitions.
>
> I would advise against using a Linux application to create DOS
> partitions.
> Partitions should be created, and formatted, in the OS they are for: create
> DOS partitions in DOS, Linux partitions in Linux, otherwise it can mangle
> the partition tables.
>
> I learned that the hard way !

Ron: as I said in my reply to Dennis, I need to read up about partitioning especially setting up from scratch, as it were.

Your comment about using a Linux application is noted.

---
Paul
Melbourne, Australia

> I would advise against using a Linux application to create DOS
> partitions.
> Partitions should be created, and formatted, in the OS they are for: create
> DOS partitions in DOS, Linux partitions in Linux, otherwise it can mangle
> the partition tables.
>
> I learned that the hard way !

Updating disks, specially large ones, with out of date tools is very dangerous too.

I've used gparted a lot, and never encountered problems. (though I haven't created FAT16 partitions with it, only fat32)

Two things ...

I had this happen once. My fan died. An rpm sensor on the mobo detected it.
A hardware signal was sent to the PS telling it to shut down. So the PC was
completely dead. A new fan brought everything back to life. Try a new fan.

As far as multi-booting goes, TERABYTEUNLIMITED.COM has an excellent bare
metal boot manager. I have 5 seperate partition groups that I choose from,
2 DOS and 3 WIN-7 on this system. This software is COMPLETEKY SEPERATE from
the installed OSs. I have been using it for many many years. Recommended.

If anyone is interested I could provide a "cookbook" as to how I have it
set up. I have it figured out pretty well.

Steve ...

> How modern? The first problem you'll encounter is whether a 64 bit system
> will run a 16 bit OS. I've seen discussions elsewhere from folks losing
> legacy MS-DOS applications when moving to a 64 bit box because they don't
> run under Win7 unless you use a virtual machine setup.

Very wrong. Ability to run a 16-bit OS has nothing to do with Win7 NTVDM issues. It has to do with CPU ability to run 16-bit code (seems still present) and BIOS (expecially INT $10 VGA and INT $13 hard disk support).

> Dual-booting isn't all that complicated, depending upon what you're
> booting. The question is whether it's the best way to accomplish
> what you want to do. In the case of running the odd MS-DOS
> application, I'd say no - go with one or another VM setup.

Good. For me - as I want to have DOS - "VM" is not a choice.

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

> > How modern? The first problem you'll encounter is whether a 64 bit system
> > will run a 16 bit OS. I've seen discussions elsewhere from folks losing
> > legacy MS-DOS applications when moving to a 64 bit box because they don't
> > run under Win7 unless you use a virtual machine setup.
>
> Very wrong. Ability to run a 16-bit OS has nothing to do with Win7
> NTVDM issues. It has to do with CPU ability to run 16-bit code (seems still
> present) and BIOS (expecially INT $10 VGA and INT $13 hard disk support).

Not wrong if what you want to do is run the 16 bit app in a 64 bit flavor of Windows. The issue isn't whether the CPU will run the code (and 64 bit Intel architecture CPUs should still be able to do it). It's whether the host OS (Win7 in this case) supports it. The answer is "Not unless you use a virtual machine."

> > Dual-booting isn't all that complicated, depending upon what you're
> > booting. The question is whether it's the best way to accomplish
> > what you want to do. In the case of running the odd MS-DOS
> > application, I'd say no - go with one or another VM setup.
>
> Good. For me - as I want to have DOS - "VM" is not a choice.

If a VM setup lets you have a fully functional DOS installation, I'm not sure why it's not a choice. But if you'd rather dual boot to a flavor of DOS, enjoy.
______
Dennis

> > Ron: my problem is that I'm not sure how to go about partitioning a hard
> > disk in that way.
>
> The first (primary) partition should go in during the DOS installation,
> whichever DOS you choose.
> After that, DOS FDISK can create and format the other FAT16 partitions,
> including any "extended DOS" partitions.
>
> I would advise against using a Linux application to create DOS
> partitions.
> Partitions should be created, and formatted, in the OS they are for: create
> DOS partitions in DOS, Linux partitions in Linux, otherwise it can mangle
> the partition tables.
>
> I learned that the hard way !

I created a FAT32 partition on my old notebook using GPartEd in Linux, and installed FreeDOS on it. Works fine.

The fun part here wasn't creating and formatting the partition, or installing FreeDOS on it - it was getting Linux Grub to boot it. That had nothing to do with the partition - it was a Grub config issue.
______
Dennis

> > Very wrong. Ability to run a 16-bit OS has nothing to do with
> Win7
> > NTVDM issues. It has to do with CPU ability to run 16-bit code (seems
> still
> > present) and BIOS (expecially INT $10 VGA and INT $13 hard disk
> support).
>
> Not wrong if what you want to do is run the 16 bit app in a 64 bit
> flavor of Windows. The issue isn't whether the CPU will run the code (and
> 64 bit Intel architecture CPUs should still be able to do it). It's
> whether the host OS (Win7 in this case) supports it. The answer is "Not
> unless you use a virtual machine."

Afaik it is not just OS. If you switch a x86 CPU to 64-bit mode, then you can't run 16-bit code natively. (because then the "alternate" mode is already pinned to 32-bit)

> Afaik it is not just OS. If you switch a x86 CPU to 64-bit mode, then you
> can't run 16-bit code natively. (because then the "alternate" mode is
> already pinned to 32-bit)

Yes. AFAIK NTVDM on 32bit windows use virtual x86 mode (that allows 32bit supervisor running 16bit sessions) to run most of 16bit code native. But when 64bit OS turn CPU to long mode it has no such capability as v86 mode (CPU engineers saved some transistors and didn't implement this legacy stuff) so you need true PC emulator then. But if I remember well I read something that 64bit linux dosemu works and can exec some 16bit code native but not sure... It's probably some experimental hack...
EDIT: from dosemu whatsnew:
- Added a native 64-bit port for x86-64, which, by default, uses CPU emulation
for V86 mode, and runs DPMI code natively.
so it seems run only dos 32bit progs native, i'm not sure...3

---
DOS gives me freedom to unlimited HW access.

> I load an old PC Magazine command line editor called CMDEDIT, in an
> enhanced version from Jason Hood.

Thanks for your post. I use DOS for a long time but I missed this nice TSR - for MS-DOS (with original command.com) it is very usefull! I replaced old silly doskey by it. Most of time I drive DOS via DOS Navigator but sometimes working with bare cmdline so it helps.

---
DOS gives me freedom to unlimited HW access.

> > I load an old PC Magazine command line editor called CMDEDIT, in an
> > enhanced version from Jason Hood.
>
> Thanks for your post. I use DOS for a long time but I missed this nice TSR
> - for MS-DOS (with original command.com) it is very usefull! I replaced old
> silly doskey by it. Most of time I drive DOS via DOS Navigator but
> sometimes working with bare cmdline so it helps.

Oh, you're quite welcome. I looked at a lot of TSR command editors back in the day, before settling on 4DOS to replace COMMAND.COM. One I used for a long time was Chris Dunford's CED, but I used an assortment of others. When MS finally got around to producing DOSkey, I thought it typical - they'd be last in line in providing something that arguably should have been in DOS all along, and when they finally did provide it, it was inferior to many of the shareware and freeware products that had preceded it. DOSKey is usable if you don't have something else, but that's seldom the case now. (DOSKey was a boon back when in corporate environments, where you might not be allowed to install third party utilities. At least you had something that could do the job.)

CMDEDIT gets the nod here for two reasons. First, it's one of the most powerful TSR Command line editors. Second, Jason has a 32 bit port that works in a CMD.EXE session in Windows, and can use the same config file as the DOS version. Jason also has a 32 bit ANSI driver port that works in a CMD window, so I can have roughly the same environment on both 16 bit and 32 bit sessions.

I have, but seldom use, products like Navigator. I'm an old command line guy, and I learned DOS back before products like Navigator existed. And I came to DOS from the Unix command line, back when X-Windows and GUIs mostly didn't exist. I had a Unix machine at home (and still have it) before I got a DOS PC, and spent a fair bit of time setting up DOS to mimic the Unix environment. (I got it to the point where it was hard to tell it wasn't a Unix system, but that's a topic for another post.)
______
Dennis

> I have, but seldom use, products like Navigator. I'm an old command line
> guy, and I learned DOS back before products like Navigator existed.

I started to use DOS (and PC) later than you, in 1995/6 so there was Norton Commander, Volkov Commander etc. and later I discovered DN that is the best. I prefer it before bare cmdline because I have various tools and function closer to my hands and instant view of directory structure. I think that 2 equal panel is great idea that was not beat till now and in my eyes windows explorer and similar are inferior.

I know 4dos and bash for dos but I like rather lightweight solution like cmdedit. I also checked win32 ver. and ansi you mentioned (even for 64bit windows, with mingw sources, maybe interesting...) Just one thing is missing - scroll back buffer (I think there are some separate utilities but for some reason I don't remember now I don't use it).

---
DOS gives me freedom to unlimited HW access.

> > I have, but seldom use, products like Navigator. I'm an old command line
> > guy, and I learned DOS back before products like Navigator existed.
>
> I started to use DOS (and PC) later than you, in 1995/6 so there was Norton
> Commander, Volkov Commander etc. and later I discovered DN that is the
> best. I prefer it before bare cmdline because I have various tools and
> function closer to my hands and instant view of directory structure. I
> think that 2 equal panel is great idea that was not beat till now and in my
> eyes windows explorer and similar are inferior.

Oh, I understand why you like it. And there are a bunch of two pane file manager replacements for explorer, so you aren't the only one who feels that way. I just got accustomed to working at the command line because the first DOS I used was MS-DOS 2.11.

> I know 4dos and bash for dos but I like rather lightweight solution like
> cmdedit.

A DJGPP or Win32 port of bash is nice if you spend a lot of time in the *nix world and want a similar environment.

I gleefully clutched 4DOS to my chest way back when because it allowed me to dispense with 500KB or so of utilities whose functionality 4DOS built in. Not just command line recall/editing. but command aliases, a full screen file lister, a vastly enhanced batch language... The only issue that could arise with 4DOS was in secondary shells out of a DOS app: the 4DOS transient portion is large, and there might not be enough RAM left in a sub-shell to load it. For those cases, I reset COMSPEC in a batch file that ran the app to point to COMMAND.COM, and loaded a tiny TSR command line editor to provide the functionality.

> I also checked win32 ver. and ansi you mentioned (even for 64bit
> windows, with mingw sources, maybe interesting...) Just one thing is
> missing - scroll back buffer (I think there are some separate utilities but
> for some reason I don't remember now I don't use it).

You don't need something external to create a scroll buffer - Windows does that for you. Right click on the shortcut for a CMD.exe instance and select Properties. Pick the Layout tab in the Properties dialog. There are two settable values: the screen size (defaulting to 80x25, and the screen buffer size, defaulting to 80x300.
______
Dennis

> Oh, I understand why you like it. And there are a bunch of two pane file
> manager replacements for explorer, so you aren't the only one who feels

Under Windows I mostly use Servant Salamander (czech product, but it's native english with localized langpacks) and sometiomes I run DN too. Under Linux is NDN port but some key shortcut doesn't works as expected.

> that way. I just got accustomed to working at the command line because the
> first DOS I used was MS-DOS 2.11.

Ah, old ancient days, respect :) If MS and IBM contined work on OS/2 and spread it I would probably don't know what the DOS is :)

> A DJGPP or Win32 port of bash is nice if you spend a lot of time in the
> *nix world and want a similar environment.

Yes sometimes needed for djgpp make to build some projects...

> You don't need something external to create a scroll buffer - Windows does
> that for you.

Oh, I meant under pure DOS. Sure windows cmd has the buffer.

---
DOS gives me freedom to unlimited HW access.

> > Oh, I understand why you like it. And there are a bunch of two pane
> > file manager replacements for explorer, so you aren't the only one who
> > feels that way.
>
> Under Windows I mostly use Servant Salamander (czech product, but it's
> native english with localized langpacks) and sometiomes I run DN too. Under
> Linux is NDN port but some key shortcut doesn't works as expected.

I have Servant Salamander here. It's one of the early dual-pane Windows file managers I looked at. There are others that offer more features, but all I normally need are dual panes for comparing directories and moving/copying/deleting files.

I have NDN under Linux. Which key shortcuts do you refer to? Keyboard support is implemented differently in Linux, so differences there are no surprise.

> > that way. I just got accustomed to working at the command line because
> > the first DOS I used was MS-DOS 2.11.
>
> Ah, old ancient days, respect :)

Just because I'm an old fart?

> If MS and IBM contined work on OS/2 and spread it I would probably don't know what the DOS is :)

Back when Intel released the 80286 CPU, everyone was waiting for a new OS that would take advantage of the chip's abilities. AT class machines essentially just became fast DOS platforms.

OS/2 was supposed to be that OS, but IBM and MS couldn't agree on direction. MS wanted to skip over the 286 and develop for the 386 instead. IBM said "No, we're developing for the 286." In retrospect, this was an error. While the 286 offered additional capabilities, it was essentially a transitional step, and the 386 was a far better platform.

While the 286 had features, it had limitations. Like you could only run one "real mode" application at a time, and while there was an instruction to enter Protected mode, there was none to leave it - you had to do a CPU reset. There were a couple of early attempts to port Unix to the 286 that had problems because the chip didn't offer the sort of hardware memory mapping and management something like Unix really needed.

If OS/2 had been developed for the 386 in the first place, and IBM and MS had been able to maintain their collaboration, we might all be running it now. In many respects it was technically superior to Windows.

The final nail in OS/2's coffin was IBM's decision not to provide support for 32 bit Windows applications. You still find it around. The last I knew, the ticket kiosks in the main railroad station here ran OS/2. I used to have an OS/2 server at a former employer for a specialized telephony application. It just ran. It there was a problem, reset it, and it took up where it left off.

> > A DJGPP or Win32 port of bash is nice if you spend a lot of time in the
> > *nix world and want a similar environment.
>
> Yes sometimes needed for djgpp make to build some projects...

Make doesn't necessarily require bash, but bash can be nice by itself. Under Windows, I run Cygwin, which attempts to port the Gnu toolchain to Win32. Instead of rewriting all of the Gnu utilties to use Win32 calls, the Cygwin developers wrote a POSIX compatibility layer implemented as a DLL. A lot *nix code builds "out of the box" under Cygwin because it links against the DLL and sees the *nix system calls it expects to use. Cygwin includes the Gnu Compiler Suite, Bash, and just about everything else from Linux.

There is also MinGW, an implementaion of the Gnu compiler suite that uses the Microsoft runtime instead of the Cygwin POSIX layer, and there are ports of bash ansd zsh for it.

> > You don't need something external to create a scroll buffer - Windows
> > does that for you.
>
> Oh, I meant under pure DOS. Sure windows cmd has the buffer.

Oh, sorry. A TSR command editor isn't intended to provide that buffer in any case. FreeDOS includes a TSR called Peruse installed at boot time that provides that sort of scroll-back buffer, which can be handy because it captures boot screens before DOS is loaded.

You can get Peruse here: ftp://ftp.pcmag.com/archives/1994/0412/peruse.zip
______
Dennis

> I have Servant Salamander here. It's one of the early dual-pane Windows
> file managers I looked at.

Hehe it seems to be popular also outside czech rep. You probably mean old ver 1.52 that is a single exe. I use ver 2.54 with lot of plugins. Dayly I use built-in FTP, sometimes SCP and it is nice to have it integrated in panel like local drive.

> I have NDN under Linux. Which key shortcuts do you refer to? Keyboard
> support is implemented differently in Linux, so differences there are no
> surprise.

I'm not sure now, ALT+Fx?

> OS/2 was supposed to be that OS, but IBM and MS couldn't agree on
> direction. MS wanted to skip over the 286 and develop for the 386 instead.
> IBM said "No, we're developing for the 286." In retrospect, this was an
> error. While the 286 offered additional capabilities, it was essentially a
> transitional step, and the 386 was a far better platform.

In this I would agree MS :) 286 PM was crappy hybrid and 386 PM still suffer with some legacy due to 286 compatability (like decriptor structures with fragmented 32bit address and other fields...). Interesting how well OS/2 later utilize 386 (I mean CPL2, so it didn't run under some simplified VM)

> The final nail in OS/2's coffin was IBM's decision not to provide support
> for 32 bit Windows applications. You still find it around. The last I

Hm, now there's ODIN allowing to run some win32 under OS/2...

> knew, the ticket kiosks in the main railroad station here ran OS/2. I used
> to have an OS/2 server at a former employer for a specialized telephony
> application. It just ran. It there was a problem, reset it, and it took
> up where it left off.

A father of one of my friend works in a bank where AFAIK they still have some machines with OS/2 Warp 4.0. My friend copied install diskettes and this is how we meet OS/2 and I must agree that it was far beyond over windows...
But sometimes it happen that inferior product wins and spreads :P

> There is also MinGW, an implementaion of the Gnu compiler suite that uses
> the Microsoft runtime instead of the Cygwin POSIX layer, and there are
> ports of bash ansd zsh for it.

I rather use mingw32 under win. It doesn't need cygwin DLL and msvcrt DLL is a standard part of windows. Also mingw gcc runs faster. But it has some tricky things like I crashed my mouth when printing 64bit ints by %lld and msvcrt needed %I64...

> FreeDOS includes a TSR called Peruse installed at boot time that
> provides that sort of scroll-back buffer, which can be handy because it
> captures boot screens before DOS is loaded.
> You can get Peruse here: ftp://ftp.pcmag.com/archives/1994/0412/peruse.zip

Yes this tool I had probably tried before (under MSDOS 6.22) and had some problem with some program together with it, long time ago...

---
DOS gives me freedom to unlimited HW access.

> > I have Servant Salamander here. It's one of the early dual-pane Windows
> > file managers I looked at.
>
> Hehe it seems to be popular also outside czech rep.

It's a good program.

> You probably mean old ver 1.52 that is a single exe. I use ver 2.54 with
> lot of plugins. Dayly I use built-in FTP, sometimes SCP and it is nice to
> have it integrated in panel like local drive.

Yes. I'm using the 1.52 version. I'm aware of the later additions, but don't really need them. I just wanted a file manager with two panes for local manipulation.

My preferred FTP client is the open source Filezilla package, and I have WinSCP here as well. I don't do enough FTP to need the capability in my file manager.

> > I have NDN under Linux. Which key shortcuts do you refer to? Keyboard
> > support is implemented differently in Linux, so differences there are no
> > surprise.
>
> I'm not sure now, ALT+Fx?

I'll poke around the next time I'm in Linux on that box.

> > OS/2 was supposed to be that OS, but IBM and MS couldn't agree on
> > direction. MS wanted to skip over the 286 and develop for the 386
> > instead. IBM said "No, we're developing for the 286." In retrospect,
> > this was an error. While the 286 offered additional capabilities, it
> > was essentially a transitional step, and the 386 was a far better
> > platform.
>
> In this I would agree MS :) 286 PM was crappy hybrid and 386 PM still
> suffer with some legacy due to 286 compatability (like decriptor structures
> with fragmented 32bit address and other fields...). Interesting how well
> OS/2 later utilize 386 (I mean CPL2, so it didn't run under some simplified
> VM)

The more interesting question is why IBM chose the Intel architecture for the PC, when things like the Motorola 680X0 were out there, with a flat, linear address space, unlike the X86 segmented model so beloved of DOS programmers. (Six different memory models, depending on the size of your code and the size of your data, with a segment on the 8088 being 64K. At least on a 386 and above, a segment is 4GB...)

Best guess is that they were already familiar with the Intel architecture (the DisplayWriter dedicated word processor used an 8086 CPU, with the UCSD P System), there were supporting chips and tools available, and they wanted to leverage the existing software base from the old CP/M machines running 8080 and Z80 CPUs like WordStar and VisiCalc.

> > The final nail in OS/2's coffin was IBM's decision not to provide
> > support for 32 bit Windows applications. You still find it around. The
> > last I
>
> Hm, now there's ODIN allowing to run some win32 under OS/2...

Is there really? Well, I guess I'm not surprised. There's an open source package called KernelEx that lets you run a fair amount of current 32 bit Windows applications under Win98. One of my contacts uses it to run Opera 11 when he needs to browse for something. (He normally runs DesqViewX on top of MS-DOS.)

> > knew, the ticket kiosks in the main railroad station here ran OS/2. I
> > used to have an OS/2 server at a former employer for a specialized
> > telephony application. It just ran. It there was a problem, reset it,
> > and it took up where it left off.
>
> A father of one of my friend works in a bank where AFAIK they still have
> some machines with OS/2 Warp 4.0. My friend copied install diskettes and
> this is how we meet OS/2 and I must agree that it was far beyond over
> windows...

Unfortunately, the OS/2 Warp server at my former employer lacked the install CD. I would have put it up at home. It's just the thing for a kiosk environment, where it's expected to be unattended and just run.

> But sometimes it happen that inferior product wins and spreads :P

Marketing. IBM was always a B2B company, and never really understood the consumer market. OS/ was superior, but IBM didn't know how to sell it. It sold into IBM shops who ran other IBM hardware and software, but never really seemed to get a lot of traction beyond it.

The folks behind the popular WindowBlinds Windows skinning package were big OS/2 fans and tried to buy it from IBM, but IBM wasn't interested.

If IBM were really savvy, they'd release it as open source. They are already open source players, releasing things like Eclipse and Open Object Rexx as open source products. An open source OS/2 might make interesting waves in the market.

> > There is also MinGW, an implementation of the Gnu compiler suite that
> > uses the Microsoft runtime instead of the Cygwin POSIX layer, and there
> > are ports of bash and zsh for it.
>
> I rather use mingw32 under win. It doesn't need cygwin DLL and msvcrt DLL
> is a standard part of windows. Also mingw gcc runs faster. But it has some
> tricky things like I crashed my mouth when printing 64bit ints by %lld and
> msvcrt needed %I64...

Mozilla shifted from building Windows packages using Cygwin to using MinGW as the build environment, because MinGW was inherently faster.

Cygwin is neat, and there are many reasons to use it, since it provides a pretty complete Linux toolchain in a Win32 environment, but there are times when you want a "native" build. (That said, I have a fair number of things here built using Cygwin. The only dependency is the Cygwin1.dll, and unless you happen to notice it in the install, you may not be aware it was a Cygwin build.)

> > FreeDOS includes a TSR called Peruse installed at boot time that
> > provides that sort of scroll-back buffer, which can be handy because it
> > captures boot screens before DOS is loaded.
> > You can get Peruse here:
> ftp://ftp.pcmag.com/archives/1994/0412/peruse.zip
>
> Yes this tool I had probably tried before (under MSDOS 6.22) and had some
> problem with some program together with it, long time ago...

Works fine here under FreeDOS, but isn't needed in XP.
______
Dennis

> I also checked win32 ver. and ansi you mentioned (even for 64bit
> windows, with mingw sources, maybe interesting...)

I set it up using a CMD file, like this

@echo off
: This file is executed at CMD.exe startup by this registry entry:
: HKLM\SOFTWARE\Microsoft\Command Processor\AutoRun

: Specify search path used in console windows
path d:\windows\system32;d:\windows;d:\windows\system32\wbem;d:\console\dos;
d:\console\bin;d:\console\usr\local\wbin;d:\console\4dos;d:\console\ebooks;
d:\Console\DCL;d:\Console\Lua;d:\cygwin\bin

set COLORDIR=
set EDITOR=vimu
set TEMP=Z:\Temp
set TMP=Z:\Temp
set TERM=xterm

: Load Jason Hood's 32 bit command line editor extension
cmdkey -c50,100 -l3 -h100 d:\Console\DOS\cmdedit.cfg

: Load Jason Hood's 32 bit ANSI display support module
ansicon -m1E -p

: Set custom prompt that creates inverse video status bar in a CMD window
prompt $e[s$e[H$e[7m$e[K$D $B $P$e[m$e[u$g
: cls


Create registry key mentioned in the code, and make the value assigned to it the initialization file you want to use. It will be evaluated every time CMD.EXE is spawned.
______
Dennis

> > There is also MinGW, an implementaion of the Gnu compiler suite that
> uses
> > the Microsoft runtime instead of the Cygwin POSIX layer, and there are
> > ports of bash ansd zsh for it.
>
> I rather use mingw32 under win. It doesn't need cygwin DLL and msvcrt DLL
> is a standard part of windows. Also mingw gcc runs faster. But it has some
> tricky things like I crashed my mouth when printing 64bit ints by %lld and
> msvcrt needed %I64...

mingw32 is migrating more and more stuff to MSys? Seens like it is at least adapting *some* cygwin aspects

We are planning to move away from a GNU make based buildsystem because of this, and the fact that the mingw coreutils are essentially 6 years old.

> 64 bit Intel architecture CPUs should still be able to do it). It's
> whether the host OS (Win7 in this case) supports it. The answer is
> "Not unless you use a virtual machine."

> But when 64bit OS turn CPU to long mode it has no such capability as v86
> mode (CPU engineers saved some transistors and didn't implement this legacy

> Afaik it is not just OS. If you switch a x86 CPU to 64-bit mode, then you
> can't run 16-bit code natively. (because then the "alternate" mode is
> already pinned to 32-bit)

Probably true, but you missed the point nevertheless. Read the original post:

> How modern? The first problem you'll encounter is whether a 64 bit system
> will run a 16 bit OS

A 16-bit "host" OS will probably NOT enable the 64-bit long mode, so it will be able to run 16-bit code.

> OS/2 was supposed to be that OS, but IBM and MS couldn't agree on
> direction. MS wanted to skip over the 286 and develop for the 386 instead.
> IBM said "No, we're developing for the 286." In retrospect, this was an error.

Maybe it was an error to make the 80286 (mostly) 8086 compatible ? Or to keep the 64 KiB segment limit ? Or to invent M$-DOG and M$-Windaube (both were already out when OSama/2 started, and influenced it) ? Or to implement support for the old M$-DOG and M$-Windaube legacy crap in the new cool OSama/2 ? It's always easy to criticize historical decisions of other people

> While the 286 offered additional capabilities, it was essentially a
> transitional step, and the 386 was a far better platform.

So why did M$ and Boreland develop for 80286 for that many years (Win16, DPMI16) ?

> While the 286 had features, it had limitations. Like you could only run
> one "real mode" application at a time

You could implement multitasking in RM too (maybe not that reliable) or use the new cool PM

> and while there was an instruction to enter Protected mode, there
> was none to leave it - you had to do a CPU reset.

+ no CPUID, no RDTSC/WRTSC, no CRC32, and the horrible 64 KiB segment limit

> In your position, I'd look at a VM solution, rather than trying to multi-boot

The HORROR of booting DOS

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

> > OS/2 was supposed to be that OS, but IBM and MS couldn't agree on
> > direction. MS wanted to skip over the 286 and develop for the 386
> instead.
> > IBM said "No, we're developing for the 286." In retrospect, this was an
> error.
>
> Maybe it was an error to make the 80286 (mostly) 8086 compatible ? Or to
> keep the 64 KiB segment limit ? Or to invent M$-DOG and M$-Windaube (both
> were already out when OSama/2 started, and influenced it) ? Or to implement
> support for the old M$-DOG and M$-Windaube legacy crap in the new cool
> OSama/2 ? It's always easy to criticize historical decisions of other
> people

This is afaik all known. IBM simply wanted to clear out 286 inventory, and keep the 386 at a premium for a time longer. Nice tiered pricing schemes as they were used to in mainframes.

Then Compaq started mass selling 386 clones, and being quite succesful at it.

> > While the 286 offered additional capabilities, it was essentially a
> > transitional step, and the 386 was a far better platform.
>
> So why did M$ and Boreland develop for 80286 for that many years (Win16,
> DPMI16) ?

Because it took some time for 386 to receive full penetration. Also the price of memory was still prohibitive. (and 386 OSes ate more memory).

> > While the 286 had features, it had limitations. Like you could only run
> > one "real mode" application at a time
>
> You could implement multitasking in RM too (maybe not that reliable) or use
> the new cool PM

I'm not going to argue any of that. I simply don't know enough about 286 PM.

I did use it, but only to get more memory in Borland Pascal. I don't know much more than that you had to be very careful to not run out of (IIRC 8192) selectors. But that could be a dpmi/heapmanager limitations (allocating big blocks from the OS, eating up a selector)

> > and while there was an instruction to enter Protected mode, there
> > was none to leave it - you had to do a CPU reset.
>
> + no CPUID, no RDTSC/WRTSC, no CRC32, and the horrible 64 KiB segment limit
>

The 64kb thing was indeed horrible. Though some of the horrors were self inflicted in retrospect, like keeping to try assembler code running with different memory models (tiny/compact/large/huge etc)

Not being able to pass a pointer in a single register made register parameters hard.

> > In your position, I'd look at a VM solution, rather than trying to
> multi-boot
>
> The HORROR of booting DOS

It depends on the uses. If you do major compilation work, a VM is only slowing. OTOH that could be done under XP too, and there is no need for native dos.

So that leaves testing the result. I would do that on an old system, and not the new one.

> > Afaik it is not just OS. If you switch a x86 CPU to 64-bit mode, then
> you
> > can't run 16-bit code natively. (because then the "alternate" mode is
> > already pinned to 32-bit)
>
> Yes. AFAIK NTVDM on 32bit windows use virtual x86 mode (that allows 32bit
> supervisor running 16bit sessions) to run most of 16bit code native. But
> when 64bit OS turn CPU to long mode it has no such capability as v86 mode
> (CPU engineers saved some transistors and didn't implement this legacy
> stuff) so you need true PC emulator then. But if I remember well I read
> something that 64bit linux dosemu works and can exec some 16bit code native
> but not sure... It's probably some experimental hack...
> EDIT: from dosemu whatsnew:
> - Added a native 64-bit port for x86-64, which, by default, uses CPU
> emulation
> for V86 mode, and runs DPMI code natively.
> so it seems run only dos 32bit progs native, i'm not sure...3

DOSEMU 32-bit: most stuff works, some doesn't
DOSEMU 64-bit: some stuff works, most doesn't

Quake (DJGPP, 32-bit) works fast as normal, but 16-bit emulation for 64-bit is painfully slow. Either way, neither is perfect (and good luck finding it from your distro), but it's better than nothing. Bugs still exist (as in all emulators), I've accidentally hung the Linux kernel at least twice now (ugh), and I'm not sure you can even use > 64 MB DPMI (default is pitiful 20 MB, eek). But it sure beats the snot out of DOSBox (no LFNs, slow as a 486) for some things (not sound, though).

> > I have NDN under Linux. Which key shortcuts do you refer to? Keyboard
> > support is implemented differently in Linux, so differences there are no
> > surprise.
>
> I'm not sure now, ALT+Fx?

Probably a clash with X11 key shortcuts. Not sure how to (re)configure that, though.

> > There is also MinGW, an implementaion of the Gnu compiler suite that
> uses
> > the Microsoft runtime instead of the Cygwin POSIX layer, and there are
> > ports of bash ansd zsh for it.

As marcov hints, I'm fairly (?) certain that even MinGW Bash / MSYS needs Cygwin (!) due to heavy POSIX reliance. Face it, GNU is all about Linu^H^H^H^H POSIX.

> I rather use mingw32 under win. It doesn't need cygwin DLL and msvcrt DLL
> is a standard part of windows.

Cygwin's DLL is unwieldy (large) and pretty much only "free" for open source stuff and sometimes slow. So people prefer MSVCRT (sadly), which is buggy (and non-free for redistribution). But yeah, everything since Win95 (w/ IE?) had (some version of) MSVCRT. Still, I prefer the OpenWatcom way, don't need either .DLLs at all!

> Also mingw gcc runs faster. But it has some
> tricky things like I crashed my mouth when printing 64bit ints by %lld and
> msvcrt needed %I64...

Also it's a "known .DLL", part of the OS these days, so you can't "overload" it with a similar (better?) version. In fact, I'm not sure how many versions of it exist, but there are many! It's a mess. I'd strongly suggest avoiding it, but I guess that's not realistic since everybody uses it (e.g. MinGW, TCC, FreeBASIC, etc). Luckily some wise people (FreePascal) also avoid it!

> > FreeDOS includes a TSR called Peruse installed at boot time that
> > provides that sort of scroll-back buffer, which can be handy because it
> > captures boot screens before DOS is loaded.
> > You can get Peruse here:
> ftp://ftp.pcmag.com/archives/1994/0412/peruse.zip
>
> Yes this tool I had probably tried before (under MSDOS 6.22) and had some
> problem with some program together with it, long time ago...

I guess you know that PC Magazine is a bit stingy these days about sharing their old DOS tools. Sad but true, just FYI.

> > > I have NDN under Linux. Which key shortcuts do you refer to?
> > > Keyboard support is implemented differently in Linux, so differences
> > > there are no surprise.
> >
> > I'm not sure now, ALT+Fx?
>
> Probably a clash with X11 key shortcuts. Not sure how to (re)configure
> that, though.

Via the .xinitrc file, I believe. Been a while since I looked that that, however.

> > > There is also MinGW, an implementation of the Gnu compiler suite that
> > > uses the Microsoft runtime instead of the Cygwin POSIX layer, and there
> > > are ports of bash ansd zsh for it.
>
> As marcov hints, I'm fairly (?) certain that even MinGW Bash / MSYS needs
> Cygwin (!) due to heavy POSIX reliance. Face it, GNU is all about
> Linu^H^H^H^H POSIX.

I don't believe so. I have the MinGW and MSYS stuff here, and there's nary a copy of the Cygwin1.dll to be found in it.

The whole point to MinGW is building stuff that's a native Win32 app. In the case of things like Bash, it means some fairly heavy code changes to use Win32 system calls instead of *nix routines, but it can be done.

> > I rather use mingw32 under win. It doesn't need cygwin DLL and msvcrt
> > DLL is a standard part of windows.
>
> Cygwin's DLL is unwieldy (large) and pretty much only "free" for open
> source stuff and sometimes slow.

It's issued under the GPL, but I believe you can get a closed source license from Red Hat for $$$. It's viral - any code that links against the Cygwin1.dll also becomes GPLed code. This has caused the odd moment of confusion on the Cygwin list, from people who were afraid that anything *built* using the Cygwin toolchain had to be GPLed. No, not really. You can use the Gnu Compiler suite to build closed source programs, and the otehr Cygwin tools to assist the process. You just can't link against GPLed code.

Cygwin's DLL is about 1.9MB at this point. Whether it's slow depends on what you are doing. Since it is attempting to provide POSIX system calls by mapping to underlying Win32 primitives, how well it does depends on how closely the underlying Win32 routines map to the POSIX calls. I believe fork is an especially thorny problem, likewise signal handling.

The slower speed bit the Mozilla folks, who switched to the MSYS tools to build Windows binaries. The instigator there seems to have been Howard Chu, the Chief Architect of OpenLDAP. See http://highlandsun.com/hyc/, under "Mozilla Hacking".

> So people prefer MSVCRT (sadly), which is
> buggy (and non-free for redistribution). But yeah, everything since Win95
> (w/ IE?) had (some version of) MSVCRT. Still, I prefer the OpenWatcom way,
> don't need either .DLLs at all!

Actually, I believe it is free for redistribution, in the sense of providing it with your program. You just can't provide source (which you can't get anyway...). And since such code can only run on Windows, it's no skin of fMS's nose.

> > Also mingw gcc runs faster. But it has some
> > tricky things like I crashed my mouth when printing 64bit ints by %lld
> > and msvcrt needed %I64...
>
> Also it's a "known .DLL", part of the OS these days, so you can't
> "overload" it with a similar (better?) version. In fact, I'm not sure how
> many versions of it exist, but there are many! It's a mess. I'd strongly
> suggest avoiding it, but I guess that's not realistic since everybody uses
> it (e.g. MinGW, TCC, FreeBASIC, etc). Luckily some wise people (FreePascal)
> also avoid it!

Building for the 64 bit environment has all sorts of "gotchas". One is probably a variant of "a pointer is a pointer is an int." In a 64 bit system, it may not be...

> I guess you know that PC Magazine is a bit stingy these days about sharing
> their old DOS tools. Sad but true, just FYI.

That's been true for years, and there was much wailing and gnashing of teeth when they implemented the policy.

But PC Mag was in the same boat as a lot of other tech magazines. When the dotCOM bubble burst, a lot of the ad revenue that supported the tech mags dried up, and many titles went online only or folded entirely. PC Mag chose to restrict download access to their utilities to magazine subscribers, to try to maintain and boost circulation. But everything they'd already published had been copied to endless archive sites, so it's not like it's hard to find most of it.
______
Dennis

> > > OS/2 was supposed to be that OS, but IBM and MS couldn't agree on
> > > direction. MS wanted to skip over the 286 and develop for the 386
> > > instead.
> > > IBM said "No, we're developing for the 286." In retrospect, this was
> > > an> > error.
> >
> > Maybe it was an error to make the 80286 (mostly) 8086 compatible ?
> > keep the 64 KiB segment limit ? Or to invent M$-DOG and M$-Windaube(both
> > were already out when OSama/2 started, and influenced it) ? Or to
> > implement support for the old M$-DOG and M$-Windaube legacy crap in the
> > new cool OSama/2 ? It's always easy to criticize historical decisions of
> > other people
>
> This is afaik all known. IBM simply wanted to clear out 286 inventory, and
> keep the 386 at a premium for a time longer. Nice tiered pricing schemes
> as they were used to in mainframes.

Not really. IBM did not design the 80386, Intel did. One of the sea changes in the industry when the 386 came out was just who made it. Before the 386, the industry norm had been to license the design so there was more than one source of product. A major customer's concern was "What do we do if their factory burns down?" IBM licensed the right to produce Intel design CPUs in their own foundries, until the 386 was released. Intel declined to license the design to other producers. They wanted the entire revenue stream, and bet (correctly) that they had the capacity to meet the demand.

> Then Compaq started mass selling 386 clones, and being quite succesful at
> it.

And for a time was able to charge a higher price than IBM, and were considered the gold standard.

IBM created the standard with the original PC, and others built to it. The result was the PC becoming a commodity with commodity pricing, where the lowest cost producer won. IBM was never the lowest cost producer, and finally sold the PC operations to Lenovo.

> > > While the 286 offered additional capabilities, it was essentially a
> > > transitional step, and the 386 was a far better platform.
> >
> > So why did M$ and Boreland develop for 80286 for that many years (Win16,
> > DPMI16) ?

Because it was there, and there was a market. They didn't see a point to waiting. they made programming tools, and supported the hardware programmers wrote for.

The original question wasn't about particular programs or programming tools. It was about the development of a new OS that could use the capabilities of the new processor.

In IBM's defense, they had promised support for the 286 to their customer base, and intended to keep the promise.

> Because it took some time for 386 to receive full penetration. Also the
> price of memory was still prohibitive. (and 386 OSes ate more memory).

386's were more expensive. Everything was. But back when, an original IBM PC with 4.77mhz 8088 CPU, dual 360K floppy drives, 256KB of RAM, and a mono monitor cost about twice what a fairly high end 3ghx multi-core Pentium box with 500MB of disk and 6GB or RAM does now. Everything is relative.

> > > While the 286 had features, it had limitations. Like you could only
> > > run one "real mode" application at a time
> >
> > You could implement multitasking in RM too (maybe not that reliable) or
> > use the new cool PM

Yes, things like DesqView did it. But you were better off if you could do your multitasking in protected mode space. The problems arose when something you did had to be done from real mode.

The 386 offered the hardware memory management to have multiple virtual real mode sessions, and that issue went away.

> > > and while there was an instruction to enter Protected mode, there
> > > was none to leave it - you had to do a CPU reset.
> >
> > + no CPUID, no RDTSC/WRTSC, no CRC32, and the horrible 64 KiB segment
> limit
> >

> The 64kb thing was indeed horrible. Though some of the horrors were self
> inflicted in retrospect, like keeping to try assembler code running with
> different memory models (tiny/compact/large/huge etc)

> Not being able to pass a pointer in a single register made register
> parameters hard.

When you are dealing with a segmented architecture, and you are trying to squeeze the last bit of performance out of the platform, you code in assembler, and deal with the horrors. One of the reasons for coding in an HLL is to let the compiler take care of that stuff for you.

> > > In your position, I'd look at a VM solution, rather than trying to
> > multi-boot
> >
> > The HORROR of booting DOS

Whether it's a horror depends on what you want to do. If you just want to run the odd DOS app, and you can run that in emulation at acceptable speed in your current environment, setting up to boot to actual DOS may be more trouble than it's worth.

If for some reason you want or need a full genuine MS-DOS installation to run stuff "native", it isn't.

> It depends on the uses. If you do major compilation work, a VM is only
> slowing. OTOH that could be done under XP too, and there is no need for
> native dos.

If you have a fast enough system and a VM, you might not care. You let your slow compilation occur in another process (or even another VM), while you do other things. Or you have more than one system, and devote one as a build system while you develop elsewhere.

> So that leaves testing the result. I would do that on an old system, and
> not the new one.

So would I.

(Back when, the lead developer for the XyWrite word processor used to write in assembler, and do his development on an original 4.77 mhz IBM PC, well after 16-25 mhz 286's become the standard platform. He figured it he could get it to run acceptably on a 4.77mhz box, it would fly on what the customer probably had.)
______
Dennis