25 replies to this topic

[L A M A]

Unless there is a Boot Manager that has an emulation layer for incompatible legacy hardware, DOS cannot to utilized right on real hardware (without OS and emulation app's overhead)

 

 

Time keeps repeating this question, How cool it would be to see Win98 (and others) on current 2016 blasting fast hardware but it won't be answered unless Bill Gates gets reinstated 

[Agent47]

Dos/FreeDOS has very little use today. The CMD prompt in Windows supports a majority of original DOS commands (some are deprecated/replaced). Windows CMD commands are lot easier to learn than "Unix/Linux" commands but any power user should know them very well in order to code batch scripts efficiently.

[Wonko the Sane]

Dos/FreeDOS has very little use today. The CMD prompt in Windows supports a majority of original DOS commands (some are deprecated/replaced). ...

With the trifling omission in recent windows (lack of 16 bit subsystem and/or lack of direct disk and memory access) that most/all the fun with DEBUG is lost forever ...

http://www.rayknight...t/debug.htm#Dbg

http://thestarman.pc...debug/debug.htm

 

@AnonVendetta

Dos normally NEEDS to be booted from a Primary partition on FIRST BIOS disk (0x80) (IO.SYS and MSDOS.SYS MUST be there), but you can use a image file fine with grub4dos or memdisk.

BUT at least at first you shouldn't EVEN THINK of running DOS on your real hardware, start experimenting in a (QEMU advised) Virtual Machine.

 

 

Wonko

[Wonko the Sane]

Well, to play games, use DOSBOX, no need to "learn DOS" at all.

For learning to use it, instead QEMU is advised.

No reason to risk botching your current system booting in a dual/triple/whatever boot.

And - particularly - DOS games used every kind of trick (+1 more) to get some decent performance, so running DOS games on modern hardware is among the most difficult things to do successfully ("normal" DOS programs are usually not a problem, but games ... ).

 

Think a bit about it, in good ol' DOS days the faster processor was - maybe - a 486DX 100 (and conversely a number of programs need to be modified to be run on today's faster processors and with huge amounts of RAM, and also some IRQ's may be assigned differently, etc.), the slowest VM will add a performance slowing of - say - 30% so, instead of having DOS running 30 to 50 times faster that it ran at the time, you will have it run only 20 to 30 times faster, and in a VM virtual disk access will be so blazingly fast to outperform by several times the fastest Wide SCSI 10.000 RPM disks only a few - very high end - machines could sport at the time.

 

Wonko

[Blackcrack]

First was Dos, then the Grafical Gui Windows, dos it is worth to learn, why? :

Dos have all this what have windows also, because, Dos it is the principle

of a Gui-system from the MS-Windows Systems and you can work further

in the cmd-prompt later more easily .

 

Linux it's the same, if you works before try to make at all on an server, without a Gui,

have you later more easier for working in the gui and you know, how it works normally.. and also in promt.

 

In dos gives the Help System "help" or binary.exe /? (so dos 6.22 if you use this and try to learn and play around with this)

optimize the Ram, ems and load different in the hight(set high) memory and so on,

with this finger trainings helps you lat6er for be better and have later more easy.

Also learn an bit batch programming it's helps also an bit

 

but if you start, then try directly tiny c compiler also play around for

more easy to coming into c programming :

http://bellard.org/tcc/

 

then, the next step, html, php and upwart ..

 

best regards

Blacky

[Agent47]

 

 

I know of people that have also used DOS/FreeDOS to fix issues and perform maintenance tasks.

 

I have used DOS to fix systems back in the days of Win98. In reality, Win98 is actually a GUI subsystem running on top of DOS.If i remember correctly, there is an option in Win98 which allows to reboot to pure DOS environment as a mean to fix issues (sort of a "Safe mode with command prompt" equivalent). However Windows XP defaulted to NTFS file system which DOS can't read (at least without third party drivers) and hence ended the glorious days of DOS boot discs as a rescue/recovery medium. 

 

If you really like to see how DOS performs on real hardware, i would suggest making a DOS bootable USB stick which is the safest option.

[Wonko the Sane]

If you want to try MS-DOS you will need FAT16 (FAT32 was introduced in DOS 7.0/7.1 which is the DOS underneath Win95/98) MS-DOS 6.22 was the last "self standing" version.

 

The point that seemingly failed to get through is that running a "plain DOS" command line program is likely to work (very, very fast) on *any* machine (as long as it has valid BIOS) whilst running any memory manager (needed to run most "advanced" tools) and any graphical program, including specifically games, it is extremely difficult on modern hardware.

 

To this you add that running a DOS in a Vm or emulator is safer, especially in a learning phase when you might accidentally run "destructive" commands and/or applications that - due to the hardware differences/issues might behave unpredictably.

 

Anyway, when (if) you want to create a primary partition for it on your real hard disk, remember CHS size limits and make the partition respect Cylinder boundaries.

 

Wonko

[Blackcrack]

8sighn per file, yes, an bit getting used to .. but then he know's

learn to appreciate the long filenames, have all his bad and good ..

and at last the good for long term ..and the future for him..

 

so, should he really start, if he want really learn, with dos 6.22 with the help possibility's and the win3.11 with tcpip

on this point he learn also something about network..

 

2gig max harddisk , fdisk and then format.. fdisk have a ascii gui

if anyone have a 1 or i,5 Gig hardddisk..

but you can also a 80 Gig maximal pationing with ~2 gig , fdisk make only the max 2 Gig on any harddisk..

like i have not forgot .. .. but he mus have a ide-harddisk ! sata it's nothing for Dos.

 

i have a couple dos things.. pm .. if.u.w

 

best regards

Blacky

[Wonko the Sane]

sata it's nothing for Dos.

Sata works fine in DOS as long as Bios has a provision for "IDE compatibility mode" or similar, in practice it will be fine on most desktops and not fine on most portables.

 

Wonko

[wendy]

DOS is as much the OS/2 and Windows Command line, as UNIX is the Linux command line. 

 

So knowing things like 'DOS syntax' is the same as knowing Windows or OS/2.  I used OS/2 help files on LAN Manager to administer windows networks, for example.

 

Some of the exotic commands in DOS, even where they are not part of OS/2 or Windows, are none the less useful starting points for searching the help file.  SYS for example, in OS/2 is SYSINST, and is somewhat different in Windows, but the purpose of these commands are to set the disk bootable.  Likewise FDISK is a useful pointer to the fixed disk program, although in Windows it is a different (and rarely used) command.

 

Until the advent of BartPE, and installing VistaPE, the usual tool for installing Windows NT on a hard drive was DOS.  I mean, as network admin, I had a number of PC-DOS diskettes to do things like run norton GHOST and other proggies for Windows. 

[Blackcrack]

Hi Wendy our Dos Fairy

because the syntax, dos it is the principle of Gui in Windows, if he learns what's goes on "behind" the Windows, know he also what's be possible or not possible.. so, it's not bad if he learn the principle of the System and so, really pretty well if he learn how dos works..

 

 

@ Wonko the Sane : Compatibility.. yessss.. but i told, "SATA it is nothing for Dos" and in this case

it is the commands from the ide "emulated" or something .. but a clean SATA it don't work,

because other commands as it is in SATA available ..

 

best regards

Blacky

[Wonko the Sane]

 

@ Wonko the Sane : Compatibility.. yessss.. but i told, "SATA it is nothing for Dos" and in this case

it is the commands from the ide "emulated" or something .. but a clean SATA it don't work,

because other commands as it is in SATA available ..

 

What you said before and what you are saying now make no sense whatsoever from a technical standpoint, and additionally it is simply not written in the English language.

 

It is always extremely difficult to try and understand what you mean, but it's OK , as long as you don't provide false or wrong info.

 

I will re-write this very slowly:

IF the BIOS has an option to support SATA disk drives in IDE compatibility mode, THEN to all effects in DOS the disk drive is a PATA (IDE) disk drive, even the controller Vid&Pid changes so that (in windows NT) it is recognized as "Standard dual PCI IDE controller".

DOS relies on BIOS services, if the BIOS tells DOS that a disk is an IDE disk and provides access to it, DOS is fine with it.

 

Wonko

[Blackcrack]

Wonko..

english nazi

and you simply the best..

 

oh jau, i know..

[Wonko the Sane]

Actually more like :

Spoiler

 

Wonko

[Wonko the Sane]

 

There are no provisions in my BIOS regarding IDE, only SATA/AHCI.

It is a laptop, right?
 
 

Sata works fine in DOS as long as Bios has a provision for "IDE compatibility mode" or similar, in practice it will be fine on most desktops and not fine on most portables.

 
It may much more sense to make a small disk image loading it in RAM, with grub4dos or memdisk, since you probably have plenty of it.

Dos normally NEEDS to be booted from a Primary partition on FIRST BIOS disk (0x80) (IO.SYS and MSDOS.SYS MUST be there), but you can use a image file fine with grub4dos or memdisk.

Wonko

[Wonko the Sane]

Memdisk will be RAM only (not persistent) with grub4dos you can choose to have it --mem mapped (i.e. in RAM just like memdisk) or using direct disk access (persistent), the only limitation for the latter is that the disk image needs to be contiguous.

If you want to install to the internal disk (the small FAT32 partiton you made on it) using the "Install" provisions you will most probably need to remap/exchange disks, DOS wants to be on first active partition of first hard disk, if you boot from USB stick, the USB stick becomes first disk, so you need to exchange devices and install from the (virtual) CD.
*like* in grub4dos:
map (hd0) (hd1)
map (hd1) (hd0)
map --hook

But you can of course deploy the FreeDOS manually with SYS, then reboot to the just deployed OS.

Fiddling with FDISK and SYS is exactly the kind of thing that may turn out as a disaster, hence the advice to become familiar with the commands in a VM ...


Wonko

[Flux]

DOS is no longer used in any manner for current systems. Although some basic knowledge of file operations and navigation may come in handy in rare situations using the console in Windows, anything further than that has little to no value.

Particular usefulness comes in when you need to run an application with additional arguments as administrator, and don't feel like making and editing a shortcut.

 

Batch scripts rely heavily on DOS commands, however if you don't have a day-to-day use for batch scripting, there comes little value as well.

 

my recommendation would be to get used to CD, DIR, RMDIR, DEL, DELETE, MKDIR, CP, MV, RENAME and DISKPART.

Other than those, really no benefit otherwise for general use.

 

PS:

I'll be entirely honest, I didn't read the full post, it was a bit too long. I'm responding to the thread title itself.

[Wonko the Sane]

DOS is an Operating System.

Batch is a scripting language.

Command.com is the command interpreter in DOS, cmd.exe is the command interpreter in Windows NT since 3.x.

Commands in a batch script are interpreted and run by the command interpreter, that has a number of internal commands, such as cd/dir. etc. that may have a similar syntax, but not exactly the same between command.com and cmd.exe.

 

Once you have learned the syntax of a bunch of internal command.com commands, you are - maybe - 10% into "learning DOS", and since most parameters will be different in Windows NT and later (cmd.exe) it won't be particularly useful if you plan to use a NT based windows, if that is the scope, forget abut DOS and study the Windows NT CLI, cmd.exe and batch scripting in NT.

 

BTW, Diskpart is a windows NT executable, (only available since XP) and not an internal command, like cd/dir, etc. you mentioned.

In the good ol' DOS days we had FDISK (which also was an external command).

 

Wonko 

[wendy]

While DOS, Unix &c are operating systems, it's the bundled utilities these come with that define the user interface.

 

The Unix interface is passed through the GNU (gnu's not unix) into the linux community, and varying attempts at the DOS group.  So if you know 'linux', it's actually the unix command interface that one learns, because each different linux runs a compiled version of the unix base utilities.

 

Likewise DOS has an interface, that has been inherited into OS/2 and Windows.  Even commands that were not released for OS/2 and Windows, were none the less made available for these (eg deltree.exe).  DOS has a number of idioms that are entirely new over unix, such as multiple fs pointers, (eg the pwd in unix is somewhere on the tree, but DOS maintains one for each block device). 

 

DOS has file extentions.  This means one could suppose that ABC.TXT is an ascii text file.  The problem comes when companies try to hack each other's extentions, so you get things like .PDF (program definition file).  It's even worse when one comes to one is gui and the other is a command line utility.

 

REXX is IBM's SAA programming language, IBM proposed a cross-os interface for all of their operating systems, but your average hacker knows this best from OS/2.  Help files were written in IPF.  The programming glue is REXX, borrows from VMS system layout, but is used in DOS and OS/2 batch files.  It is a wonderful light language, still fits on a floppy disk, and still quite servicable.

 

BASIC was the previous 8-bit dominate language, and its retention in DOS (BASICA) and MSDOS (GWBASIC) is because of this.  However, it's not really a shell extension.  It does not integrate into STDIO in the same way that REXX does.

 

QBASIC and a great range of proggies like Visual Basic for Whatever, shows exactly how not to implement an interface.  I used qbasic to test VBA proggies, and the like, but you don't just run a good old rexx script in a word processor.

 

There is CENVI, (or rather, was), it was fairly nifty in its time too.  It's a c--, but different in nature to the Sphynx version.

 

It's bad when the Windows CMD.EXE shows that it is a broken port of the OS/2 one.  One has for example 'keys on' and 'keys off', which sets a variable keys=on or keys=off.  Another juicy one is 'DPATH' which sets the dpath variable, but Windows does not use it.  Unfortunately EXTPROC did not survive the cut from OS/2 to Windows.  This is vaguely useful, and even 4OS2, 4NT and the current TCC support it.  It allows you to run a batch under a different processor.

[Wonko the Sane]

It's bad when the Windows CMD.EXE shows that it is a broken port of the OS/2 one.  One has for example 'keys on' and 'keys off', which sets a variable keys=on or keys=off.  Another juicy one is 'DPATH' which sets the dpath variable, but Windows does not use it. 

 To be fair dpath is undocumented, but it's the same as append, and supported by (say) TYPE

https://github.com/n...discovers/DPATH

http://ss64.com/nt/path.html#dpath

 

Wonko