Hi there :-)

>> The kernel and command.com are probably on the
>> (compressed) boot floppy image on the ISO, so
>> you do not see them unless you boot from that
>> CD.
> 
> I don't remember. Ask Bernd.
> 
>> Maybe we should also put the files on the
>> ISO directly, for those who want to use them
>> without having to boot from the CD or having
>> to take extra steps to reach the files...
> 
> Maybe. I mean it's not the worst idea.

Bernd, what do you say? :-)

> But (for now) end users can always just grab them manually via network:
> 
> 1). http://sourceforge.net/projects/freedos/files/
> 2). http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/

Thanks!

>> Rugxulo has some boot floppy images as well
>> as the files from them and the sources online:
>>
>>> https://sites.google.com/site/rugxulo/
> 
> Too old, too obscure, too buggy. It was just too hard to keep them
> perennially up-to-date (not to mention the hassle of always chasing
> licenses) and test and release and ....
> 
>> If you "just want to SYS your C: drive", it
>> can be easier to use those...

What I mean is that a floppy image - 1.44 or 2.88 MB - is
probably a nicer starting point for making a bootable USB
with Rufus compared to putting the whole ISO on a stick,
in particular if you only want to run SYS and FORMAT :-)

>> Exactly. In particular, "mkdosfs" (of Linux
>> dosfstools) or some Windows FORMAT tool will
>> NOT put a boot sector which loads the kernel
>> of FreeDOS.

I mean: The boot sectors created by formatting tools in
Linux and Windows will not search for a FreeDOS kernel
and load it. For that, you will have to use the specific
FreeDOS tools, either the DOS one or my Perl script :-)

It is a bit ironic that Vista is the first which helps
you to resize drives but also the first which no longer
has this easy to configure boot menu for loading DOS.

>>> USB jump drive is probably your best bet. Although you can
>>> "probably" use Eric's sys-freedos-linux (Perl?) script, if
>>> direly desired.
>>
>> The tool is a Perl script which calls nasm to
> 
> Which Perl?? Ugh, I hate the idea of ten bazillion unsupported,
> incompatible Perl versions.

No worries, it is only 170 lines, from 2008 and
not really fancy. I think it should work even on
newest versions of Perl. As long as you remember
that it has to invoke Nasm (assembler, i.e. an
assembly language "compiler") to make a FreeDOS
boot sector based on your custom choices :-)

Obviously you also have both in Windows, too, but
my Perl tool can only put boot sectors in a disk
image: In Linux, that means you can also apply it
directly to the "device" view of partitions, but
Windows does not make it THAT easy... Rembember
that you also have to MANUALLY copy the files of
kernel and command.com to the drive that you want
to be bootable: My Perl script only helps you to
make a boot sector, it does not copy any files.

>> In short, it is easier to use SYS after booting
>> DOS from anything that can boot DOS, such as an
>> USB stick or CD. Note that booting from USB or
>> CD can have an effect on drive letter "numbers"
>> so make sure that you use SYS on the drive that
>> you actually want to use...

In other words, do not accidentally SYS the stick
that you booted from anyway, it may show as C: ;-)

> "Fast" is subjective, even with Ghz. Emulators are usually *way*
> too slow and *way* too buggy ... unless you have VT-X, but even...

Actually thanks to hardware assistance, you often
get near-native speed. People often run multiple
smaller virtual servers on a single big physical
server or on a cluster: This allows making use of
the fact that usually load peaks do not happen at
the same moment on all servers. Also, it allows
easy changes of the distribution of RAM and CPU.

> So DOS is faster, simpler, and more secure.  :-)


DOS gives you 100% of the CPU time for yourself,
apart from at moments when you ask the kernel to
do stuff for you. However, DOS apps and the DOS
kernel share a single CPU core while modern CPU
can have 16 or more cores in a single chip :-)

There are some experiments with direct access to
other cores in DOS, but this only works with lots
of manual tuning of your sources, I would assume.

In Windows and Linux, you would simply use standard
library calls (for example in C or Java or any more
trendy language) to create additional threads, tasks
or processes and the operating system will distribute
them over your available cores automatically for you.

Cheers, Eric



------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Freedos-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Reply via email to