FDSHIELD has no problem with loading to UMBs: If the selected UMB
is too small, then the stack pointer will be too low when the UPX
stub of the compressed FDSHIELD starts, and the stub will exit to
DOS at once, before any damage is done. If you do not UPX FDSHIELD,
then you cannot load it to too small UMBs anyway - it does not need
more RAM than the decompressed binary size (plus a small stack,
but even if you start it with "no" free stack space, the stack will
only overwrite part of the help message.
Anyway, if you like, you can create a sample EXE binary, which should
be UPX compressed (either before or after converting to EXE, as long
as it is compressed at all) and at most 4 kB in size. Enjoy :-).
(Do not send exe files by mail, put them into an archive first and
mention that it is for FreeDOS...)
Second issue: Interactivity. If you select "write protect disk", then
FDSHIELD will reject write attempts. No message which asks the user
whether he really wants the write to be rejected. Reads are always
allowed. In which situations did VSAFE show a warning about BIOS-based
(int 13) direct disk READS?
Third issue: Examples. The syntax is:
> FDSHIELD [/?] [/v] [/x] [/X] [/b] [/B] [/t] [/T] [/w] [/W]
I recommend to use the /v /X /b /B /t options for everyday "non-admin"
use of your system: FDSHIELD shows verbose messages that way, prevents
any removal, creation or modification of program files and boot sectors,
and rejects any TSR or driver load except RTM and CWSDPMI. So you have
to load the shield after your drivers and TSRs.
The /w and /W switches would write-protect diskettes and other disks,
but the hardware write protection is better for diskettes anyway, and
write-protected non-diskette drives can really confuse DOS (it shows
a prompt "retry?" but does not allow you to abort, at least MS DOS did).
If you use both /w and /W at the same time, all files and directories
will get simulated read-only attributes. So DOS gets less confused. But
you cannot use pipes and redirection if all your drives are write-protected,
so write protection is generally not very useful.
Why would you want to use /T? Because you run DOS in a box which already
supplies DPMI. Most DOS extenders do not load as TSR anyway, and CWSDPMI
is not needed if your DOS box provides DPMI. Only RTM stops working if you
use /T in a DOS box. Why would you want to use /x? Because it allows you
to modify BAT files and to create program files in ways which make it very
clear that you do not attempt to modify or overwrite them. However, this
is not useful for most compilers / unzippers / exepackers... anyway, so I
would just say "Use /x to protect com exe and sys, and /X if you also want
to protect bat".
For "admin" mode, you can probably only use /v, because everything else
can spoil admin things like program installation, driver loading, disk
formatting, and so on.
Explanation of the suggested default FDSHIELD /v /X /b /B /t switches:
Verbose operation, protect com exe sys and bat files from any messing,
protect boot sectors on all FAT disks (including MBRs) and halt the
system if TSRs or drivers except RTM or CWSDPMI load (in DOS way - note
that viruses tend to load in more sneaky ways which are not detected).
You should load UDMA before FDSHIELD - if you load it after FDSHIELD,
then int 13 based disk or boot sector write protection for harddisks is
bypassed. If you have /t switch of FDSHIELD on, you cannot load UDMA
after FDSHIELD anyway ;-).
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
Freedos-user mailing list