Hi Arkady, 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 ;-). Eric ------------------------------------------------------- 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. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
