ZapDH0 ------ By John Davis, Version 1 October 1989 Version 1.1 April 1990 Version 1.2 24 June 1990 Version 1.3 26 June 1990 ( 1.2 didn't last long did it :-) What it does ------------ All you 2090 owners .... ever get _really_ annoyed with that forced OldFileSystem DH0 partition? It's bad enough that you hvae to waste 400k of disk space with the OFS partition, but what is really inconvenient is that you can't cancel the device ( sends you off to meet the guru ), and therefore means you can't assign DH0: to be the FFS partition. This in turn means that all those _nice_ programs with install programs that want to install to DH0, or those equally _nice_ programs that give you file requester gadgets only for DH0 aren't much fun at all ( okay ... call me lazy, but newzapping three zillion programs so as DH0->FH0 is not my idea of fun ... at this point I should say a big thank you to all _real_ programmers whose filereq's know what the _current_ dir is and start there, or even better those that know how to scan a device list for available devices < not hard ... see the included example code for ListDevs > ) Well this program is just for you. What it does is munge it's way through the DOS device list, looking for that 'orrible DH0 node . When it finds it, it alters the DeviceNodeName so as it's name is now ZH0. You are then free to assign DH0: onto your real main partition. On top of this, if it detects that you have a df2: floppy disk but no df1: it will create a 'clone' drive called df1:. This is linked (arghhh ... creeping unix terminology :-)) to df2:, and helps with programs that only have gadgets for df0: and df1:, or if you (like me) have got used to typing 'df1:' when referring to the second drive (old a500 traits die hard it seems) Usage ----- Pretty simple really, just chuck ZAPDh0 somewhere in your startup-sequence. It is _probably_ safer if you do it once you've assigned everything over to the FFS partition, but it seems that it's pretty safe to put just about anywhere (as any existing dos locks to dh0:blah will still point to the _old_ DH0: ... it's just any new references that will get the assigned DH0). eg .. in your startup-sequence ZAPDh0 assign DH0: fh0: From now on all references to DH0: will refer to FH0:. If you want to acces the OFS partition, you still can (unlike if you use assigndev), it's just now called ZH0: ( and you can still access it via workbench). Plus ( if you had a df2: but no df1: ) you'll find you've grown a df1: as well. Incidentally, should you want to STOP the floppy rename ( due to problems or if you just don't like the idea ) then just add these lines to your startup-sequence instead of the above : ASSIGN DF1: sys: ZapDH0: ASSIGN DF1: ASSIGN DH0: fh0: ( I don't check to see if an existing DF1 is really a device or just a dir, so the assigned df1: will fool me into not touching the floppies ) Warning ------- This program is what CBM tech support would probably describe as 'wildly illegal' ... I access structures in a manner I've got no right to. As such I cannot guarantee it will work on any given setup, nor that it will work in future releases of the OS. I have tested it on 2000's with 2090's,on 500's with A590s and on C-Ltd drives, and it's worked ok on all of them. BUT - there is now warranty implied or express on this package!! If it causes your hard disk to explode, killing your cat and causing you to have a nervous breakdown, it is NOT MY FAULT. However, if you do experience any strange side effects or any other problems with or due to this program, get in touch so as I can see about remedying them. Revision History and Tech Notes ------------------------------- v 1.3 ----- Time for a total rethink of how the df2: floppy is renamed to be df1:!! Plus a general code cleanup ( was starting to look a tad loosed in there). Previous versions just altered the name field of the df1: devicelist node in place, this worked great for the 99% of the programs that went by the rules for working out what the host device was ( by host device I mean the underlying block structured device the filesystem level device sits on e.g for df0: the host device is trackdisk.device unit 0), but it turned out that some programs were wrongly assuming that there would ALWAYS be a correspondence between the devname and the trackdisk devce unit acting as host ( that is df1: is unit 1, df2: unit 2 etc ... which is normally true, but assuming this is NOT an officially supported practice ). ! Included in this archive is ListDevs, a small example program that ! shows how to LEGALLY work out what the host device for a given dos ! device is, plus it shows how to extract a lot of other info on the ! host-dev - based in part on code posted to UseNet by Patrick ! Horgan. ! You should NEVER assume a connection between device name and host ! device and/or it's parameters .. cos sooner or later CBM are ! likely to change them ( to support higher densities or the like ). ! REMEMBER .. if they don't state it in the RKM, it's NOT safe to ! assume it!!!! This release gets around this problem by instead 'cloning' the devicelist node for df2: back into the devicelist as df1:. This effectively makes df1: an alias for df2:, and still costs <100 bytes of memory. This allows ill-behaved programs (Virusx4 and the ARP install were notable offenders) to work ( like why is it that two of my favourite programs, by some of the programmers I respect the most, have to be the one's that do things illegally :-( :-) ). I've tested the cloned drives fairly extensively, and everything seems to work as it should with them. This includes correct operation thru WorkBench, and with format and diskcopy ( format df1: puts a lock on BOTH df1: and df2:, diskcopy df1: to df2: is the same as diskcopy df1: to df1: in that it will prompt you to do disk-swaps ). However, the df2: clone/rename is still basically illegal operation (a.k.a a neat hack :-), and it is possible some programs may not like having a drive clone done. Hence, if anyone experiences any anomalies due to using Zapdh0_1.3, could they please contact me ( stating what program had difficulties ). v 1.2 ----- My conscience got the better of me, the floppy rename is now handled in a safer manner (unlike 1.1). ZapDH0 now first looks to see if there's already a DF1 in the system ( an internal 3.5 floppy ). If there is already a df1: it leaves the floppies alone (otherwise if you had an external as well you'd end up having two DF1:'s !! having this happen wasn't much fun). If it can't find a df1:, it looks to see if it can find a df2: and renames it if possible. v 1.1 ----- Nothing mind-blowing I'm afraid ( boy, what I'd give to get rid of that slowfilesystem partition altogether, guess I'll just have to buy a 2091 ). All that's changed is that ZapDH0's output is now cleaner, PLUS it now also renames Df2: to be df1: (for people like me with one internal and one external floppy, but who are too used to df1: being the second drive) It still renames DH0 ( if found ) to be ZH0 (it simply traverses down the DOS devicelist and changes the name field in devicelist node for dh0: -> zh0: and for df2: -> df1:). To see exactly how this is done ( I smell BPTRs :-) refer to the source code Licence Agreement ----------------- There is none !! ZapDH0 is absolutely 100% Public Domain (and is dedicated to all the other PD authors who help make the Amiga a great machine). If this program makes you happy, and makes your life a little easier, that's good. If you feel obliged to thank me, then that's alright, I always enjoy getting letters from fellow amiga users. If it makes you unhappy ( i.e. it's got some bug I haven't found ), then also write to me. My contact adress is ..... John Davis 31 Clarence St Christchurch 2 New Zealand or you can find me on AmigaINFO BBS NZ +3-371-531 1200/2400 Baud 24hrs a day "home of the midnight coders" or you can reach me via Internet/UseNet as CHEM194@canterbury.ac.nz