load kernel is-dos.

Press RESET immediately, All! 22 Mar 01 00:12, Kirill Frolov wrote to All: KF> There is is-dos recorded on a screw... There is its core (inside the driver KF> screw) recorded by the sv.com command. We need to somehow download and launch it. I've finished playing... iS-DOS is no longer available on the hard drive. I still downloaded it (via boot FDD and isrld). And there, as the default screen driver, was ty64.typ. You can't really see anything in the panels. :-( Well, I used his command set.com ty64.typ /e decided to delete it. DO NOT REPEAT THE EXPERIMENT!!! Then something terrible happened - screw loud rumbled and the light bulb blinked, colored squares appeared on the screen... When I pressed RESET and loaded the kernel a second time, then the file system on the screw was no longer it was! :-( As I understand it, when removing the screen driver, the remaining drivers were shifted to memory (by the way, the screw driver was installed AFTER the screen driver, that is below address) and some part of the system began to mistakenly call the screw driver with these consequences... :-( The following conclusions were drawn: the screw and/or its driver need to be protected from erroneous requests in case of failures such as incorrect deletion of residents or simply the program leaving random address. I still have little idea how to do it. Protection against accidental calls drivers can be created by a third-party program in some other way (meaning completely randomtransition to the driver memory area). And from not random but with the wrong ones parameters? No thoughts. :-( P.S.: I still don’t know how to load the kernel from STS. P.P.S.: There is a very simple way to install iS-DOS on a screw from a PC: in Linux just 'dd if=file.img of=/dev/hdc1

Greetings, *Kirill*! Thursday March 22 2001 at 18:55 Kirill Frolov wrote to All about "load the kernel is-dos." KF> The conclusions are as follows: the screw and/or its driver need to be protected from KF> erroneous calls during failures such as incorrect deletion of residents or KF> simply leaving the program at a random address. How to do it while I'm presenting KF> weak. Make protection against accidental calling of the driver by a third-party program KF> is there any other way (meaning a completely random transition to the area KF> driver memory). And from something not random but with incorrect parameters? Thoughts KF> no. :-( There is a small program that prohibits recording to the device, it was written by Prusak and Phoenix (PHD), maybe it will help... here is a help from it: === Cut === The protect procedure allows you to protect combat logical device from random records on it. This is useful in protecting against incorrectly working programs. For example this program can be used to protect a device that is difficult to restore, whom, like HDD, or archival device. The utility can work in either mode menu (when starting without keys), and in console mode. When starting in modemenu, a sign appears reflecting the Protecting available disks. Familiar "-" displays the recording prohibition on the device swarm, and the “+” sign allows entry. Opposite non-existent or inaccessible devices nothing is displayed, and rubbish does not move through them. By pressing the key Vis "ENTER" you can change the status of the installation swarms In console mode, the recording format is coy: [path]protect [/ds][/ds][...] where: d-device name (A-H or a-h) s- sign "+" or "-" There can be several keys in quantity set device statuses. If in console mode, syn- tactical error or will be indicated but non-existent or inaccessible mouth- swarm, the program will exit with the message about the error. For example: set write protection to drives A: and D: protect /A- /D- For example: remove protection from drive E: and put it on drive C: protect /E+ /C- ***************************************** 02/13/2000 Bagan Sergey and Polyakov Alexander ***************************************** . === Cut === How about soaping? All the best to you... Bye!