I still think having true functions in batch files would be a good thing
turn batch files into more capable language
On Tuesday, May 21, 2013, Eric Auer wrote:
Hi!
Your vision on DOS is somewhat, well, interesting ;-) So
there is a lot to chat about, although I am not sure if
the KERNEL list is the right place for this topic. DPMI:
I would expect performance gain to be minimal. Maybe there could be
Low/HMA/UMB memory savings with a different architecture. Hard to say.
Well there could, but why would it matter? More heavy DOS
software normally uses DOS extenders / DPMI anyway, which
means it does not care about how much low DOS RAM is free.
The HMA is mostly used for the kernel and buffers, so as
long as the kernel fits in there, no others have a heavy
need for it. Only a few drivers may use it UMB style.
Also, caches put bigger buffers in XMS, not needing HMA.
Finally UMB is mostly used for drivers: You could write
drivers that use DOS extenders / DPMI if you really have
a lack of space. Actually the simulation of SoundBlaster
16 that comes with SoundBlaster PCI works like that.
Probably also some commercial NTFS drivers, because NTFS
is complex and you do not want to spend 100s of kilobytes
of DOS memory only for loading a filesystem driver...
USB, PXE and CD/DVD/BD drivers as drivers / in memdisk:
I lean this way too w/respect to drivers. Built-in's biggest advantage
is
You still have to configure built-in drivers, you only
avoid the risk that you forget to include the file in
your boot disk ;-)
simplicity in user configuration. However, networking seems to be lacking
throughput speed with either mTCP or Watt32 apps. I'm not sure if it's a
packet driver, TCP/IP stack, app (doubt), or kernel (doubt) issue.
Networking in DOS means that your app has a compiled-in
network stack which communicates with a packet driver to
get the low-level hardware stuff done. You often have a
small buffer for that and little concurrency. There may
be a bit of IRQ and DMA, but big operating systems are
more relaxed about juggling with multiple streams of net
data with support from complex chips on your network card.
Note that this is just an educated guess: Ask our experts!
guess is that it's a 16-bit MOV/LD* loops, the lack of zero-copy
networking, and the switch between kernel and app. I've seen some
No switch: The kernel does not network at all and there is
only one app at a time using the network. Depending on how
your packet driver and network stack library work, you do
not need many steps of copying either and the transfer to
or from a buffer is unlikely to be a big bottleneck with
modern CPU, I think. However, as said, you probably work
with little bits of data and small buffers in DOS, because
you may have less orchestration between stack and driver.
reference to the same ... USB drivers as well (USB 1.1 speed from USB
2.0 devices or 3.0 devices). And there seems to be 3 ways to get USB
That problem far much more trivial than you might think:
USB 2 and 3 are controlled in ways that differ a lot from
USB 1, so many drivers simply do not talk USB 2 or 3 at
all. This is not like AGP, PCI or PCIe where you flip a
few bits and suddenly I/O to your graphics card is fast.
It is more like the difference between paged graphics at
a000:0 and a linear framebuffer, to stay in the example.
However, there is no linear USB. Talking USB the 2 or 3
way is just a quite different language, but as you know,
at least one shareware driver speaks it and knows the
dialect of at least some relatively widespread chips...
working on DOS: USBDOS, DOSUSB, Panasonic/ASPI Method. I need to play
Enjoy :-) And maybe do some benchmarks. Even the shareware
driver should work long enough for that - I think it just
blocks after a while after each boot, but is not locked in
terms of how many days or years you have it installed.
On the other hand, I think it would be an interesting experiment
to have a kernel which can load files from at least the root dir
of ISO9660 or UDF disks and similar (ext2? ntfs?) and which can
directly interpret GPT partition tables...
Yes! I agree! The FD Kernel needs to speak MBR, GPT, ISO9660 UDF
(including El Torito), NTFS, Ext2/3/4 to stay relevant. Probably HFS+ as
well. Linux and/or FUSE should be helpful here.
Uhm no. You do not agree ;-) Yes the kernel should speak both
MBR and GPT. Something about 4k sector size is also a good
idea. However, El Torito is only so-so as CD/DVD/BD driver
and Jack's drivers are probably better. It would be fun from
an academic point of view to have ElTorito-ISO9660-GPT in a
kernel, but even Linux works great with kernels-without-any-
disk-drivers when you put the drivers in the boot-ramdisk to
load them as separate files from there. DOS with MEMDISK is
basically the same.
Having (separately loaded) drivers for ISO9660 (we do, even
with long file name
