Eric Auer wrote:
> In general, one of the Wattcp
> and Watt32 annoyances is that it does not keep DHCP
> config in "general" RAM, so each time you start some
> network app for DOS, it asks the DHCP server again?
Later Watt-32 programs cache DHCP information in %TEMP%\W32DHCP.TMP.
Robert Riebisch
> even an unexperienced programmer should have no problem to give Int13
> access
> to his fance RAM disk
The difficulty (or inexistant difficulty) of giving some device Int13
access isn't my point. *Not* giving Int13 access for any block device is
the reason for the DOS block device architec
>> as a matter of fact, all SCSI/RAID/USB/whatever disk devices are
>> either Int13-visible (using the boot eprom for SCSI/RAID or by
>> emulation ), or not visible at all.
> Ever heard of DOS block devices? Think of a RAM disk. It'll usually
> install a DOS block device so that DOS can access i
> as a matter of fact, all SCSI/RAID/USB/whatever disk devices are
> either Int13-visible (using the boot eprom for SCSI/RAID or by
> emulation ), or not visible at all.
Ever heard of DOS block devices? Think of a RAM disk. It'll usually
install a DOS block device so that DOS can access it's FA
> I'm talking about non-FAT DOS block devices. This especially includes
> (beside Int13 devices) any SCSI/USB/whatever device that is _not_
> accessible through Int13 (and therefore invisible to usual Int13-only
> local filesystem redirectors).
no idea what you are talking about.
as a matter of
Hi,
>>> Character devices can be found by their name and can be
>>> controlled via IOCTL... In addition, because you pass
>>> the device name as command line option to CDEX, this way
>>> is slightly more end user friendly than int2f handlers,
>>> in particular if you have more than 1 CDROM driver
Hi,
>> Character devices can be found by their name and can be
>> controlled via IOCTL... In addition, because you pass
>> the device name as command line option to CDEX, this way
>> is slightly more end user friendly than int2f handlers,
>> in particular if you have more than 1 CDROM driver load
Hi,
> Character devices can be found by their name and can be
> controlled via IOCTL... In addition, because you pass
> the device name as command line option to CDEX, this way
> is slightly more end user friendly than int2f handlers,
> in particular if you have more than 1 CDROM driver loaded.
N
Hi!
>> You could write such a driver but you have to remember that "DOS
>> block device" already implies FAT anyway.
>
> This implication is a part of the problem I'm talking about. DOS (rather,
> the DOS device loader) shouldn't assume that just FAT exists (it also
> shouldn't discard non-F
> You could write such a driver but you have to remember that "DOS
> block device" already implies FAT anyway.
This implication is a part of the problem I'm talking about. DOS (rather,
the DOS device loader) shouldn't assume that just FAT exists (it also
shouldn't discard non-FAT partitions fr
Hi!
Not all DOS USB disk drivers are one part... A driver
pair that works well is for example USBASPI ASPIDISK
where the former gives block level access while the
latter connects DOS block devices to those partitions
on the USB disk which are FAT formatted. You can have
(write) some ASPINTFS driv
> This is already what DOS does, sort of. DOS has no separation of
> access rights, so there is no userspace, but it has a layered
> system of drivers. The kernel supports BIOS int13 drives as well
> as FAT filesystems. After booting, you can load drivers to give
> the kernel access to the sectors
>>> Why not, say, Samba? There already is smbclient for DOS.
>
> Note that smbclient has the look and feel of a text
> mode ftp client. It does not create local DOS drive
> letters for your remote network shares or anything.
Because that would require a full-blown DOS version that hooks into the
Hi!
>> The extensions I'm interested in are mainly those that allow me to
>> access newer filesystems so that the people who use my tests won't
>> whinge as much about having to transfer files from DOS to NTFS or the
>> like.
> Perhaps something like FUSE (Filesystems in Userspace) could be por
Hi!
> Just make regular backups, and keep a clean image.
> Make one before you go in the interwebz.
> Got a virus? Just wipe the disk and put the image back.
As you do not always notice the virus at once, you
better also keep older images. Or maybe you keep a
few generations of backups of your p
I use FreeDOS because I have an old laptop which is somehow too slow to run
DSL. I installed FreeDOS on it and I'm currently using it for keeping a
journal on and writing an interactive fiction game in TADS.
Since I'm keeping a journal on it, it needed to be lockable... which DOS
traditionally has
I use DOS for running burn-in testing of new machines which are then imaged
with various versions of Windows. The burn-in logs are written to a network
share; the DOS networking clients work fine, though I haven't had much luck
with DOS as a server. Does that count?
> -Original Message-
I've found a packet sniffer BUT not a signal strenght program..
see
http://www.perotti.ic.cz/wavelan/pvdemo%5b1%5d.zip
roberto
duparc wrote:
>
> Did you got any answer ?
> Thnks
>
> Zitat von iw2evk :
>
>>
>> Hi ,
>>
>> someone know if exis a wifi utility for monitoring the wifi activity in
On Sun, January 18, 2009 19:28, Eric Auer wrote:
>> As far as web browsing and dos, isn't dos susceptible to almost
>> every single virus on the planet? Another thing, some people
>> want to run dos thinking that it can't browse the Internet.
>
> DOS is too old to support modern viruses, so unles
On Sun, January 18, 2009 09:02, Jim Lemon wrote:
> The extensions I'm interested in are mainly those that allow me to
> access newer filesystems so that the people who use my tests won't
> whinge as much about having to transfer files from DOS to NTFS or the
> like.
Perhaps something like FUSE (F
20 matches
Mail list logo
