Hi, I found that the RTM (DPMI16BI) DOS-extender insists on staying in RAM as a TSR when you run programs like Jazz Jackrabbit or other Borland-compiled protected mode programs. Does anybody know a workaround for that? For example DOS4GW and DOS32A stay in RAM as a SHELL for the protected mode program, which is okay for FDSHIELD "malware effect limiter" (well, call it a virus shield, but it has no idea of what a virus is!), but I would really prefer to have "do not allow programs to go TSR" mode compatible with Jazz Jackrabbit... A virus shield which is turned off all the time because it is not compatible with popular games makes little sense.
Next problem is CWSDPMI, which is used by all DJGPP-compiled apps, including INFO-ZIP (surprisingly, ZIP tells CWSDPMI to go TSR, while UNZIP does not... ZIP uses go32stub around an UPXed program body - UNP reports 2k header/code and 84k overlay - while UNZIP is a LZEXE compressed 16bit binary... Probably UNZIP does not need much RAM to have full performance?). You can avoid the "CWSDPMI is going TSR" shield problem by loading CWSDPMI -p before loading FDSHIELD, but then CWSDPMI eats a nice amount of low RAM :-(. Is there a way to load DJGPP-compiled apps in a way which opens CWSDPMI in another style, e.g. as an overlay or as built-in stub? Anything which does not trigger "going TSR"? If I do not get this figured out, what should I do: - make FDSHIELD allow programs which have the name RTM or CWSDPMI go TSR (should there be at least a warning displayed?), even though this creates a gaping protection hole? - make FDSHIELD allow RTM or CWSDPMI go TSR based on some hard-to- fake properties of them, like checksumming a bigger part of the resident code or searching some bigger string? How many versions of RTM / CWSDPMI do you think are in circulation? The "hard to fake" idea is that including a bigger part of the known-good- DOS-extenders would make viruses suspiciously big. As basically no new DOS viruses are written anymore anyway, even checking for the name RTM / CWSDPMI would probably be enough already, and maybe for some minimum resident size, the latter to HOPEFULLY trap the case of RTM / CWSDPMI themselves being infected and the piggybacking virus instead of the DOS extender trying to go TSR ... well, what the heck. I do not check for "do it yourself MCB fiddling" or "allocate some RAM and forget to dealloc it on exit" or anything at the moment anyway. Even DEVLOAD "bypasses" the shield. - keep FDSHIELD as is, but know that people will not use the TSR- shield feature of it because it prevents them from running Jazz...? The best solution would of course be telling people how to load RTM *before* FDSHIELD, so they can keep the shields up and still run the game :-). For CWSDPMI, I would like to know a non-preload solution, because the memory overhead is quite big. Any ideas? Well, at least you CAN preload CWSDPMI. For RTM I do not even know how to do it at all. Any help / comments welcome. Eric PS: You can also run with only exe-file protection ON and TSR protection (in turn) OFF. This works quite okay but some demos want to "unzip" embedded exe files to disk while they run. No idea, maybe some games do the same? In addition, some (very few) programs insist on writing to themselves as part of some weird protection / registration scheme every time when you run them. Of course you then have to reboot with "shields down" whenever you want to install or remove a new program. Sounds okay. ------------------------------------------------------- This SF.net email is sponsored by: 2005 Windows Mobile Application Contest Submit applications for Windows Mobile(tm)-based Pocket PCs or Smartphones for the chance to win $25,000 and application distribution. Enter today at http://ads.osdn.com/?ad_id=6882&alloc_id=15148&op=click _______________________________________________ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel
