Programing diary for :- BlitzDms - Written in Blitz2. Start date :- 3rd December 1995 Completion date :- Release date :- Author/s :- Anthony Brice & Paul Juhasz ============================================================================= Notes ----- BlitzDms will be a gui interface for DMS 1.11 which I use quiet a bit here and there for checking demo disks etc, and the one I use now is great apart from it generates errors and occasional guru's on certain options. I want some custom options in such as undms'ing to HD if possible, or at least a rad disk which is why I want to write my own. ============================================================================= December 3rd. ------------- KillJoy is basically finished now. It's up to my partner in crime to do some more work with it tidying up lose ends, and any bugs that I might have missed. BlitzHatch is supposed to be the next little project we work on which will be a file handling system between points and Sysops where the sysop generates his own config file with it based on the file areas on his system, and he gives this config to his points who will then use the same program to configure the user side with their details such as addresses etc, and then they can use it for sending files from their computer into file areas in the config and blitzhatch will add them to the flo files, and send a .bh file with it so that the recieving sysops system runs blitzhatch in process mode at his end and it will upload these files into the correct area automatically. Kind of like a tic file system except these aren't routed on, hence the avoidance of using that system as I've done in other arexx programs. Anyway enough of BlitzHatch, this is BlitzDms and is basically a little solo project based on what I know now about blitz to keep myself busy inbetween sessions on that while it's in Pauls hands. A Dms window shouldn't be that hard to program once you have the base gui, but I'm begining to wonder otherwise :-) GadToolsBox was used to create a gui to work with today. I've incorporated gadgets to control everything possible with 1.11 of Dms at the start. I can't see much point in making it work with higher versions of DMS as there's a few trojans out there, and the one I use now is the last official release by the original authors, and hence pretty safe. And it works fine. Wether it has the options for undms'ing to hd etc which I really wanted to have in if I'm going to do my own window anyway, is another matter, but I'll start simply as it can always be tweaked later on as long as there's no need to totally redesign the gui. I did have an earlier gui created with the gadtools.bb2 program itself, which I'd probably have used had it not been for the fact that I compiled it all up into source, and then generated it into raw code and lost the bloody source so I had to go and start over. Gadtools box is so much easier to use , and intuitive as well, so it's far more my preference. BlitzGuiGen by Simon Archer then makes short work of generating source code within a working program too. Only quit works obviously but at least the gadgets can be clicked around with so you get an idea of how it feels. Plus you can use getfile gadgets with his program, even if they are hacks more than nice code. Tweak with this source to opimise and include some functions which I can use that we did for Killjoy and it's just a matter of tidying it up. Not to mention renaming all those variables which say KillJoy to BlitzDms as they are in the imported functions ;( December 4th ------------ More hard work. Up and running after a lot of problems with sorting out the gui again after I ran amok stripping the thing down. I'm not sure still how fonts work with blitz so that's where my problems lay, along with silly mistakes like using deftype.s for numeric data :) Decided to go full hog with the thing and have some configurable stuff right from the out.. As I've used tooltypes already they were the logical choice, and the config path can be put in here anyway for starters. Much work later and we have the obligatory public screen options (If you want it elsewhere) and you can choose your preffered font, as long as it's 8 point that is :) IconX and Y stuff is in there in case I opt to test out this iconify stuff at a later stage (Not played with that as yet) and also put in X and Y position options for the main window. Hopefully I've got rid of the obvious bugs at this early stage such as making sure the font has .font added to it , if the tool line doesn't etc. And making sure that we default to Workbench and other stuff if there's no custom bits in the tooltypes. I've got a requestor in there if the program can't find the icon (A straight rip from the about requestor) to read in tooltypes, but I can see that getting anoying. I'll need to find out how blitz can find what directory it's run from and then just make it use defaults if it can't find it there. Yeah, great, but what does it do now? You ask. Nothing yet. Well the about gadget pops up a requestor :-) I fancy making the window an appicon so you can drop a dms file onto it and it will prompt you with a Load or Save path requestor, and add it into the gadget field there. A nice touch I think. Hmmm maybe just throw it into the load field. You'd not have an icon for a save file until you'd dms'd the chosen disk :) December 12th ------------- Holidays don't half bite into programing time. No great loss though :-) Just back from Belguim and it's time to do some more work. Fiddled around getting the load and save path buttons to actually pop up the file requestors for path names. Much fiddling around trying to set their flags so they'll pop up on the correctly configured screens, and that was after trying to suss out why the procedure wasn't being called, which turned out to be me putting the code into the wrong case statement so they'd run if the text string gadget was used. I've put in some stuff now to update the gui status which I can add to as more of the gadgets start to do something. Now it will update the gadget strings when a path and filename are selected. It's not working properly by any means as I think I'm running the routine to update all the time instead of just when an actual gadget is clicked that affects something :( I'll look into that tommorow. The requestors need to use a #?.dms wildcard ideally as well, but I haven't sussed how to do that as yet, which is a bummer. Also we have a flashing cursor problem and delayed gadget response as soon as I try to edit the paths manually instead of using the requestors. Definetly the gui update routine suspect here. The paths can't be changed as yet either. This is going to take more time than I originally thought! December 13th ------------- Put in the variables for all the gadgets status today. That way the config file part will be able to slot in pretty soon. Updated the gadgets init bit to use the new variables instead of hard coded defaults and it's fine there at least. Just finish off setting variables for every gadgets status and we have the data we need to save to disk to create a config file and read it in when the program first runs. Why a config file now when the program doesn't do any dms shit yet? Well this way I can set defaults up for testing and they'll be set every time I run the program instead of messing with the code manually. :) Fixed up the routine to get the file paths. Works now but still doesn't pop onto the correct screen unless it's compiled. Strange that but it's just cosmetic at the moment, and probably won't matter once it's compiled anyway into an executable as it works fine then. The gui update stuff has been fixed now. Works nice and the long delays between gadget response has been removed at last. You can't edit the file paths by hand as yet (well you can but it doesn't change the data in memory yet) but that shouldn't be too hard to correct. A quick look into the killjoy source should fix that one. Ditched the GTX gadget for drive types.. For some reason I couldn't find a way to read it, and it didn't provoke a return flag like the other gadgets. Some modifying of the gadget position, and changing it to a cycle gadget , and it functions just as well and now works properly :) And finally for now, I've got the strings in the filepaths printing when first run, and not after a gadget is clicked. Sloppy :) Didn't think I'd be able to stop working on it just yet. Did a shitload more this afternoon. The variables and flags are all set for the configurable data and the gui update routine works with all of them. Put in the Save config file routine now. Works great. So I bunged in the routine to read the config at the start of the program before the gui is booted up, as it now knows the save format. Put in a requestor to inform the user if there's no config file so they can either click on the "I'll save one in a minute!" button, or just abort. Can't see why they'd want to abort just because there's no config, unless they want to change the tooltype line that points to the config path, but you never know. Both routines work just fine and it's ready for use when I test out the dms bits which will come soon now. I need to sort out the file requestors first though. We're getting path names in the filename text fields, and other shit which needs to be fixed. The public screen stuff is annoying as well. Must fix that up properly, so it's time to wade through a heap of #IDCMP stuff again trying to suss those out :( Summary basically is: FileRequestor fixes. Status line on gui needs to report messages. Start Button needs to start something. Then we should be ready to create a command line to pass to DMS now we have variables for the gadget settings. Getting there :-) December 15th ------------- I've spent the last three hours odd configuring up the file requestor routines for both Load and Save gadgets to make them work intuitively. The idea being that they'll pop up on the correct screen, have the current path stored as part of the config file (Handy for peeps who keep all .DMS files in one drawer) and use appropriate wild cards etc, as well as making sure that the right arguments are passed back and forth so there's no bits in the wrong place such as the filename in the path gadget, or the whole path and name in the file string etc. It was a pain in the arse making it work so well, and chances are nobody will even notice it, or just assume that it feels okay to use because it's automatically like that, and not due to me spending ages making it like that. :( Shame really, but that's programming for you. The file requestor stuff all works lovely now so that's another bit out of the way. I'd move onto the status line text display routines now but it's the infamous Barnet Piss up tommorow, so I've arangements to make. Might finish this thing one day. Unless tommorows (which will here-after be known as day of the Playstation) christmas present for myself, makes me give up coding forever and play Destruction Derby until the end of time, I don't know. Also fixed up the pathing when the program first loads. It'll find its icon file no matter where it's run from now. Thank god for Relic programmers with usefull information to help out the newbies. December 26th ------------- Kinda dead for a while. Blame Christmas. Figured the funky stuff was kinda drifting off the plot for a while, so I got the console window up and DMS doing it's thing at last. Took a couple of hours to get it running properly without the dreaded guru's and the code's a nightmare waiting to happen. I've still got some minor problems with how options are passed to DMS from the gui but it's not really anything major right now, and it is working at last. I've definetly decided I don't like how DMS works with its arguments. READ and WRITE TO Device, etc.. All to easy to call it the wrong way as you use read to read a disk to a file, and not logically read a file to disk etc, so it's rather dangerous using the thing if you don't know what you're doing. I mean DMS itself btw, not my gui Due to all this confusion I ripped out one of the path gadgets and text fields to minimise problems like this where you need a different path to save, than you would to load, and you don't know if dms is going to save over the file it's meant to load from etc. That was one of my bitches with the original window I used (Which looks like it was written in blitz also as a matter of interest) and I don't want another confusing program like all the rest. I need to again sort out the path field so you can put a name in manually as it's suddenly stopped working when I took it all apart (A normal occurence with me :( ) and I've been concentrating on rebuilding the bitch after such a drastic change of plan in design. The console window is severely hard-coded right now as well. That should really change if there's options to change everything else so I may well need a couple of new gadgets to set the console width,height etc anyway as it's a little barren on the gui right now. Either that or just take the easy route and whack them in as tooltypes. Contemplating the idea of putting all the configuration stuff into tooltypes and making blitzdms just modify the icon every time you save the config instead of using a seperate file. Much less chance of fucking something up then, and removing the need for a config path tool line as well. I'm pretty sure there's some routines for adding a tooltype as well as reading them in with the library I've used so far. December 27th ------------- Sigh, playstation blues. Tekken :-) That thing seriously distracts me from doing anything at all code wise these days. Took a serious effort to switch the thing off earlier and get on with streamlining the mess I left the source in last night. I was having one of my: It's-working-so-fuck-with-it-tommorow-when-you- are-awake kind of days so I left it right buggered up as it was compiling okay at that time. What a job cleaning it up again. Still the deed is done so it's time to concentrate on making the new stuff a little more customisable like the rest of the program. Hmmm that's a pretty tidy peice of work there if I say so myself ;) Just did some shifting around with the file requestor routines and the convert filepaths into the directory and filename seperate into its own procedure so I could use it from the text field being modified as well as the button to change the data with the requestor. Works bloody lovely too. Makes a change for me :-) And just to wrap up I've put in the four new tooltypes to configure the info that the console window will use for its display pattern. Could have put it into the gui but if I opt for the config all stored in the tooltypes (as I think I'm going to do) then it's not really nescessary. Maybe I'll find a way to let the user pop one up, adjust it to how they like it, and it'll store the info in a tooltype anyway when they save config. Better get some docs done now I guess. January 2nd ----------- Fixed up the Path string not being updated after a file is chosen with the file requestor. One of my routines was fiddled with by a friend who fixed some other bits of the program. I've patched it temporarilly until we sort his bit out :-) Another tooltype has been added (PROMPT=YES/NO) This is a dodgy one but it will supress the requestors confirming what action dms will take after you select the start button. Some people won't want to click on Okay all the time so they can switch it off, but it means there's no last minute abort button if you have set it up wrongly. Docs are now updated with new information and features put in since I first wrote it. January 11th ------------ BlitzDms was in Pauls hands until now. Poor bugger's been right through it re-arranging everything and implementing shit-loads of new features, and then when he passes it back to me today, I realise that he hadn't had my latest version so some of the new stuff such as the Requestor suppression etc were not there. He'd craftilly just commented out the code manually :) Spent the afternoon fixing that (inbetween Playstation sessions ) and checking both versions so I could fix up his one with the nescessary new bits that I'd put in. That's one of the major hassles of two people working on a program if they lose track of who's got what, and both work on it at the same time. Still the deed is done. BlitzDms now has (after Pauls fiddling over the last few days) a font sensitive gui (I was meant to sort this out, but he beat me to it :) and an iconify feature with a zoom gadget which I hadn't thought about. The source is a nightmare to understand now as he's made so many changes, but I'm working on it. The font sensitive routines still need some tweaking, but they do work, if not for all of the text, so it's nearly there. In the true spirit of delegation, I've opted to let him finish what he started, and fix it all himself, while I do the stuff I do understand (IE: What I wrote) and fix out those little bugs which I keep finding still. This program will end up the most bug-proof on first release ever, I suspect. I won't mention the nasty little re-arranging of the icon tooltype names that a certain co-author has done. Suffice to say it took me ages to work out why this bloody program wasn't working all of a sudden, before I twigged. Yet another update of the doc file is called for soon. I'll leave that until I've finished with them though, as I've done more tooltype work again today, such as putting the PROMPT= one back in for optional disabling confirmation requestors and new ones to specify the iconified windows X & Y start points. I'll have the width and height ones done once I've dug deeper into the code as they didn't work when the reading routines were put in, and the new flags were Paul's work, wheras the other two did. The Save Path stuff has made a return after strong insistence from every one (especially Paul) who said it had to be there, or it was just confusing. I have to concur. I know how the program works so I probably wouldn't have a problem using it, but others might, and did when I passed it to people on IRC the other day to run the executable on a few different amiga's to check on compatibility etc. So the Save gadget and file path are back where they were in the first place. Talk about re-inventing the wheel. This took a lot of fiddling and changes to the config file to get it intuitive again. January 13th ---------------------- BlitzDms has had more work done by Paul on the font sensitivity and the ugly gaps between gadgets and window headers have been fixed. Also the drive list works properly now and only allows selection of a drive available on the system. All of the config and gui options are now totally converted to tooltypes. 2 hours work, and 2 hours debugging. A right bloody pain. Still at least there's no more config file anymore, and it's totally obsolete. There's a couple of gadgets which aren't initialised according to the tooltypes even when they are read in and saved correctly, but that one's in Pauls hands as he's re-written the routines that use them, so I'm not sure how to fix them. And I'm basically lazy :-) I'm thinking that all of the configuration stuff should be able to configure from the gui. Font selection, and maybe public screen if there's a way of getting a list from within blitz. A couple of new gadgets can possibly be crammed in - a getfile gadget to select a font, and it'll update the gui on the spot, and a button to choose a public screen, which also acts accordingly. Maybe some menu options to do this to save reworking the entire gui to fit more in. Tuesday, 16-Jan-96 - 04:02 --------------------------------- Hooray!!! I managed to fix the PubScreen problem!!! :)))))))))))) From now on BlitzDms will fall back to Workbench if the configured Public Screen isn't available. :))) There could now be a menu-item (once I fix the menus) to jump to any pubscreen as with KingCon. ;) As it is now, when it falls back to WB and I do a snapshot, the tooltype PUBSCREEN will become "Workbench" (case sensitive!). So if you were to Save Prefs after jumping to the Zeus screen, it would be the place where BlitzDms would appear next time it's run. But this all happened just now. Monday and the day before I was still struggling with reading the iconized state window position and the fact that the put_tool routine would only save now and then and only when it felt like it. The obvious is always soooo difficult to find - adding new tooltypes when you DO NOT have a file and vice versa - also freeing the object in every case isn't too clever either... For some unknown reason which I have yet to track down, the program still loses exactly 40 bytes (?!?) every time it's run!!! Grrrrr. :I It /could/ be possible that the little skirmish with my chosen one had something to do with the big discovery - well - at least it drove me to open the BIG HEAVY BOOK and have a look at the Autodocs. Would a CD be nice - or /would/ a CD be /nice!/ #B)= The snapshot facilities - to be flash about it - for both zoomed and standard window sizes do work now too. There was a need to change the tooltype variables to make them less confusing - like CON_X_WIDTH and CON_Y_WIDTH...!?! Actually - I changed that stuff to a more sensible approach, like CON_LEFT, CON_TOP, CON_WIDTH, CON_HEIGHT. %) The problem of accidentally packing an Empty disk on top of a very important archive - that's fixed as well, so now you get a requester asking you wether you want to overwrite the file or reselect - this meant that I could redesign the way the Load and Save Path requesters work and clear up the IDCMP loop even more. Nice. ;))) As a side-effect, you don't need to pre-select your paths now, just select WRITE/READ or whatever and click on Start. If there is no filename, a filerequester will automagigally pop up and tell you what to do. Ideal for a lazy old relic like myself. ;))) And of course it's a step along the path towards the App thingy. ;) Another thing - when I had a long path, the Prompt-Requester tended to run off the right edge of the screen - I had to put some Chr$(10)'s in between to space things out a bit... While messing with the above fixes, I started on keyboard-shortcuts, partly because of the state of my mouse-port and partly to help me take my mind off the problems. Rawkeys are all good and fine, they will work quickly and easily, but Menus with key-shortcuts are more the biz. So I decided to attach some - just for the fun of it. A few MenuItems got added - I was hoping to get those key shortcuts - using the newer BBGTLib.obj_MIK I found on one of the bums. Don't work yet quite as intended - at all! - but then lots of things didn't work to begin with and now they do. ;)= The rest of the program seems to work without a hitch, but those menus just refuse to appear. Very strange. No doubt one day they will suddenly decide to do what they were supposed to and pop up... .-) There is still a slight problem with the fallback to default-font - if the selected font isn't found, it reverts to topaz, not the system font, but if you save the configs, the incorrect font is saved - without the .font extension. :( So the items on my list to be fixed: a) Default Font b) GTMenus c) I'll think of something... At the moment I feel a bit worn out so I decided to leave the menus alone and pass the proggie back so my boss can have a look and play - while I have a go through Loot and see if I can find a place to live. Thursday, 18-Jan-96 - 06:51 --------------------------- Yipppeeee!!! What a good day it has been yesterday! ;))) First post my fuse arrives - not from the original people who promised, but from Dart Computers where I ordered it from on Monday. Good to do business with professional people. :))) An hour later it is soldered in place of the old one and I've got one working Alfa Data mouse with a sexy red light glowing under its belly. ;) Excellent start to the day, although I have to have a few hours kip after having been up all night last night with those blasted GTMenus... :I Still, now I'm even happier - the menus work. The fonts took a bit of thinking about and experimenting with before I was satisfied with the way it all works, but the Menus drove me to drastic measures. I had to use the Blitz Debugger and trace the fuckah!!! First let me explain the fonts. The default font doesn't have to be the old Topaz - we're way past OS 1.3 - but any fixed-size font that is set up for system use - ie I use script so that's what I get in Shell, etc. If anyone is happy with Topaz, they're welcome to it, I even modified my old A1000 KickStart disk to use a font called look - much nicer. ;) Anyway - if the font you ask for is not available, or too big to fit the re-sized window on the screen, BlitzDms now reverts back to the sytem default font. This is the one written out in case you Save Prefs too... With that done, I've done some cosmetics to the About requester - looks better now. Just then Janice came home - she's made a few calls and we have some flat to look at in Clapham - 2 bed, inc CT and WR - 390 pcm - we'll have a look at it Saturday. Back to the Menus. After changing all the gadget-id's to use constants (ie #G_About) - I was then able to start the gadgets at 50 - this is recommended in the FM. Then I had to insert the BBGTLib.obj_MIK into my blitzlibs: and do a makedeflibs. No good. Removed the old BBGTLib.obj as I've forgotten about that. It is the older one and doesn't support GTMenus (?) - this new one also has a GTArea gadget for gfx - the GTShape isn't too clever apparently. And the Menus...? It was a stupid wrong flag... #:| Still - phew - finally I'm ready to let anyone else have a play with it - I couldn't very well send out a non-working program, could I? Now I have some time to look into those Appthings... ;) January 18th ---------------------- Refixed the prompt pause if DMS is in TEST or VIEW mode. Not sure why Paul disabled it, but that's relics for you ;) Put in new information to have a configurable DMS version to use. Currently supports 1.11 or 1.53, but perhaps more can be added later if there are any. Menus and hotkeys have been fiddled with to add new options for selecting dms version. Could use a little improvement to perhaps have a tick beside preffered version, but it works for now, as does the amiga hotkey so who am I to push it? I've updated the save and load tooltype procedures to include the new feature. Note: The #MI_ functions have two new definitions for now which have been slotted in at 3 and 4, so the ones higher than this have been raised naturally. Due to the way these constants are used (and what they're there for in fact) this won't make any difference to how the program runs. I could get used to these things now that I'm using them the correct way. Fixed the stupid position bug where I created the menu items in the wrong order. Now all menu items are available again :) Need to look at dms 1.53's command syntax now to incorporate it into the start_dms procedure. Probably just a re-adjustment on how the args are laid out on the executable string, but I'm not overly confident :) Been playing around trying to fix up the routine that checks if the icon is present and offers you a requestor with use defaults/Abort. This routine doesn't work it would seem as I found out when testing it, as I intended to remove the requestor and revert to defaults automatically. Buggered if I can work out why. It looks like I'm going to have to resort to a dos check for file_exists instead of relying on the geticonobject return code which doesn't return false if no find the thing, like it should. Tommorow anyway. Time for some kip now :) Looks like Paul was working on it at the same time and we've had another clash.... Here's his entry which he's done on his version without my changes so I'll use that one to put in the bits I've done on mine later on today. Friday, 19-Jan-96 - 09:44 ------------------------- Changed height of inner bevel box to 27. that of outer bevel box to 35. Moved BinSys Text gadget down by 1 to 82. This is all in readiness for the graphic to go into there (use 1:1 with font_y 39, else size down), see BinSys_Logo.bsh. Replaced "?" button with MX type buttons to select your DMS version. Presently at 1.11 or 1.53 - has no effect as yet. Those will be as follows: a) DMS V1.53 WRITE mode has added keyword VERIFY - added checkbutton b) DMS V1.53 has additional commands - Append - still to do ReadHD, WriteHD - these could replace the normal READ|WRITE when the DD|HD cycle is on HD - High density floppies. The gadgets have been implemented now, so this was given version 0.74. When the Version MX gadget is on 1.11, the HD|DD cycle gadget gets disabled. As MX gadgets work immediately, ie NOT on GADGETUP, I had to include a Case GADGETDOWN where the MX gadget gets read and the Density cycler gets enabled/disabled. Also it would be possible to DMS a RAM Disk - should we include that with the other drives? Ram: RAD: RRD: VD?: SD?: ;) Sunday 21st January ----------------------------- I gave up trying to snip bits out of mine and into Pauls. Too fiddly, and it's not really worth the effort change-wise anyway. I'll work on his version from now. Knocked up a simple little gui that will eventually be the front end in creating the keyfiles for the release version of BlitzDms. Nothing much there in the way of generating routines yet, but I've got a rough plan on what format they will take, and the type of information to be stored so I'll figure that stuff out in the background while I finish putting the gui together. It's the usual read tooltypes for config options program and 5 simple buttons to do the buisness, not to mention requestors for every error possible so it'll keep me busy while Paul's fiddling with the main program anyway. Monday 22nd January ----------------------------- Updated the BlitzDms Keymaker program to change the gui a touch and remove the Iconify and size gadgets. They're not needed, and using the sizing on the window shagged it up anyway as it isn't designed to resize, and doesn't need to with 5 buttons anyway. The main program needs to have all those flash functions, but as the keyfile creator would only be used by either me or Paul, it wouldn't. Did some more working on a keyfile system. I've got some idea on how it should work now, it's just a case of sorting out what info needs to be in there. Not had much time today for much else due to BBS fixing and testing a new mailer. Wednesday, 24-Jan-96 - 05:48 ----------------------------------- Went through the code and implemented all the features behind the two versions of DMS. This meant that the DmsPath variable had to contain the command name as well as the path, it was replaced by two variables called DMS_SDS and DMS_PDX. When there is no DMS command selected, either by pressing Start or by toggling the MX gadgets (1.11/1.53) you will get a Filerequester asking for the DMS command for the current version. With the HD floppy option ON, the READ/WRITE commands get internally replaced with READHD/WRITEHD. This hasn't been tested fully. :( Added new DMS command Append (1.53) which is selectable from the Mode cycle gadget, selecting DMS1.53 will enable this option. All new options are read/written from/to icon tooltypes - all seem to be working now, even the latest tooltype additions for CON ALT values. Okay, so it's getting there - Appwindow feature next...? ;) Thursday 25th January ------------------------------- <.. Keyfile creator..> Fixed up the routines that check if the icon exists so they actually work when the program is compiled to disk now, and not just compile and run from within blitz. Had to opt for a dos check as the best way to find out if the icon is there no matter where the program is called from, be it cli, or workbench. Won't work if the program is renamed to something else, but that's not really likely anyway. Must remember to modify the BlitzDms program itself to use this way of checking. Adapted the About window to show your configured path and keyfile list. I just put this in so I could check the tooltype reading stuff got the correct info but it's probably worthwhile to keep it in there anyway for reference when the program is running. Fixed up the silly bug in reading in the tooltypes to start with. It wouldn't ever read in the tooltypes even if they were there before :( We now have Version 0.03 :) Adapted source code slightly so the program information can be configured from the first few lines. This way a quick change of these lines and the way keyfiles are created, and I can use this program for keyfiles for future progs that Paul and I come up with if they are to be shareware. Friday 26th January ----------------------------- <..still working on the keyfile creator..> Paul has fixed the drive select bug with the main program at last :) The keyfile creator is now generating keyfiles. It's not complete by any means, and hasn't got any of the list functions for storing them, or any number stuff so they can be tagged individually. In fact it doesn't even have any checksum stuff in them yet, but I've devised a way of encoding data with them based on a customisable string in the generator, and it's working pretty well at the moment encoding stuff such as name, address, email address etc. A base to work from for sure. Saturday 27th January ------------------------------- Did more work on the keyfile creator to fix up some abort buttons so they would abort the operation and not just carry on anyway. They kind of slipped past as I wasn't testing those parts until I reached a clean break in the programing and went through tidying up after myself. The program seems quiet a bit too padded out where shorter routines could be used but I don't think it's really worth trimming it down too much as it's only going to be used by me and Paul anyway, and it'll do the job. I'm definetly not happy with the way it's generating keys now. After a little thought I need to change quiet a bit to make sure there's some devious checks in there. Once I've actually generated keys which will be used by the main program then I'll not be able to play with any of the core routines on this program as it would make old ones invalid, so I need to get them acceptable now. I'm opting for two types of keyfile now anyway. The points who have agreed to beta test it for me will get normal keys that won't ever expire, but the oicks on IRC who I'm warey of letting lose with the program will get keys that are time coded to expire within a month from a certain date. Everyone has the clock running on their machines these days near on, especially those on the internet, so if they don't come to me after a month saying there keys are no longer working then I'll know they weren't actually testing it properly anyway. The program should have been finished and be doing the rounds by then anyway. Had a look at the blitzdms source code again. There's a bug with the public screen functions no longer working. Didn't notice that one until I asked someone to test it this evening and practically called them a liar when they couldn't bump it to another screen. Did it myself just to make sure and the relic has snapped something. Bloody old fart :) At least I hope it's him anyway. Sunday 28th January ----------------------------- More minor work on the key creator. I'm probably not going to get this bugger finished by the time Paul wants it back to start on the appicon routines so I've come up with a temporary workaround. It'll do until the keyfile stuff is 100% agreeable for me. Back into the blitzdms source code, and I put in various flags for handling key checks etc. It's all handled by a couple of variables now, and the keyfile check routine is just a dos check if a file exists. If it's there then for now BlitzDms assumes its a valid key and works as if the program is registered, whereas if it doesn't find the key, then it'll become unregistered, giving me a chance to put in all the restriction code. Now BlitzDms will pop up a requestor which needs to be cancelled 5 times when it first runs, before the gui pops up. Kind of like the time out requestor for Spot, except it's not time related yet. I may make it do that at a later stage though. Just a matter of reading in the clock before displaying the requestor, and if it's been a certain amount of time displayed, then it can be cancelled, which is how Spot does it. It also removes the ability to save the configuration stuff as tooltypes. The user can still edit them manually if they wish, but obviously it's a hell of a lot more convenient to drag the window where you want it, etc, and just hit save config rather than working out the right position all the time. Not to mention the other config options, of which this program has far too many to even think of gloating about them here :) AppIcon support will also not work in the unregistered version, but that parts down to Phineas I guess as he's already hatching plans to get the code of me and write it. And naturally the About requestor will end up displaying all the registered users details and a unique registration number. Monday 29th January ----------------------------- Looks like I've just landed a week of work on doctors orders. Might even get a serious amount of work done on this thing at last now :) Flipped back to the key generator again. Time to finish up a new format and be done with it. Keyfile details will now include:- Name Email/fido address Date of creation Keyfile number Normal postal address Version number of Keyfile creator that made it. And some kind of crc check of the data stored in the key so it can be checked for hex editing. Tuesday 30th January ------------------------------ Shit load of work on stripping the keyfile program and making it compile smaller, and tidy it up. Learnt one hell of a lot about using procedures with multiple arguments, got temporarilly confused between the differences between statements and functions until I realised that you can't pass variables back from a statement unless they are shared, wheras you can with functions. Got the key program down in size by 20k to 56k odd using tricks where multiple loops are switched to functions etc, but it'll be a bit more when I put it all back to normal, as some source is commented out to skip tiresome checks which don't apply while only I'm using it. So far we have a 200 byte key which is generating properly, and being displayed correctly. I'm going to bump up the size a bit, but the encryption is working pretty cool as now the User name, address and email address are in, so there's half of it done anyway. And as the encryption string is already done, then it's just a case of bunging the rest in, so it should be plain sailing. The recognition string may well change later on anyway as the program has been designed from the start to work on two fields as I previously mentioned, so any different conversion list for the second field and it's instantly a new keyfile. I'm rather proud of it actually :-) I've got a routine in for getting the date using a dos command. I'm not sure of any other way to get around that as yet, so I'm waiting on some feedback, but it'll do for now to get some kind of string in. I'll do no permanent keyfiles until I'm happy with how that works anyway. Put in some code for the Show Key routine. I'll need to have that actually read in an encrypted keyfile and get the correct information from it to display in a requestor, as well as the keyfile itself, so it needs to be done at the same time as the generating key stuff while I can still remember how they work as it's so complicated. The idea being I can then just lift the key read stuff from here and plonk it into BlitzDms and it'll work just fine as the key action stuff is already in the main program. Changed the gui around a bit on the key maker as a check keyfile option isn't really needed from what I can see. Show keyfile will show both the normal keyfile details, and a dump of what the key looks like in its requestor anyway, so the check key gadget has now been changed to Show key list, and that will eventually show the file created with this program that has all keys in one big file, along with data from each one as it reads them in. Maybe a list view at a later date for programing practice, but for now it'll just be a requestor jobbie as there's a lot more important tasks to get on with. Having all the keys in one big list file as well as seperate has an advantage in that the key maker can read it in and know how many lines it is, so it will know what the next keyfile number to use should be, and also it's a quick way of backing up the lot onto a floppy somewhere instead of doing them all individually. Should someone lose a key then I can just strip one out of here from an option in the keymaker which I'll put into it after the main blitzdms program has been released, as the keyfile generator will be used for other projects I think, so it'll be a worthwhile option. But it's just a case of doing that clever stuff later on as it's not needed yet. Also means I wouldn't need to keep copies of all the keys myself which is handy too. Having some problems with reading in a keyfile that's been written. Keep getting some rubbish built in blitz requestor saying it can't access default input or something. Never happened before, but I can't exactlly get away with not having a default input statement after I've started reading in from a different device (IE: an open file routine) or it'll just overflow and bring up a requestor anyway. Could be something to do with opening a file with lines longer than 80 chars I suspect, and I'll have to look into it. I wouldn't mind so much, but the blitz default requestor even spells default wrong. Sheesh, and this is meant to be professional :) Scratch the above possibility. Just whacked in a While Wend routine to read in the keyfile a character at a time, while checking for EOF etc, and it still has the problem. Have to find another way now :-( Friday, 9-Feb-96 - 04:07 ------------------------ The last few days were spent looking through RKRM's, anything to do with Public Screens. Very nice to have such a lovely OS to provide us with these facilities. Not very nice to have Blitz ignore them and go its own stubborn way. After a lot of single-stepping through the program, recompiling and going through it again and again, I have come to the conclusion that Blitz is looking for a pubscreen Title - not the name of the screen, but its flipping Title. But not always. "Amiga Workbench" will be found as Workbench. Spot is okay too, that has the same Title as its Name, but the problem was with GoldED. Both KingCon and ScreenSelect2 will report the GoldED screen as GOLDED.1 - however, the OS routine LockPubScreen() looks for "GoldED.1" - while Blitz can only find it as "GoldED". This gets problematic, as for any Blitz specifics like SetMenuStrip or AttachGTList we need to have initialized a Blitz object BDmsScr with the Blitz command FindScreen. We also need a pointer *Scrn that needs to be initialized with the intuition.library routine LockPubScreen_() - this will return the pointer, while the Blitz command doesn't return anything and cannot be tested, only trapped with SetErr End. Without that, when no screen is found, it's Guru time - 80000020...??? If the screen pointer isn't found - when BlitzDms opens on the GoldED screen, there is no visual-info so the window/zoomed positions/sizes can be messed up, the bevelbox doesn't appear and the shell opened for DMS goes onto the Workbench. Also there will be Enforcer hits. E is beginning to look more and more attractive - maybe not as friendly to us humans as it is to the OS, but on the other hand everything can be done through the OS... Still, that's how it looks like now. There is no PubScreen fallback to Workbench - it could be done if I knew the screenobject internals so I could initialize it instead of using FindScreen - using a nice little Assembler routine as a cheat-mode... There is a "command" in the intuition.library - LockPubScreenList() - which should allow us to step through the list of screens and copy them for our own use. Obviously it should be unlocked asap to allow them to function again, but it would be possible to set up a ListView from which to chose your screen. Blitz doesn't like it. At all. I will have to try it in C or E, just to see wether I made some stupid mistake or is it really Blitz. Without that working, there is no user-choice of screens. I've done some other little bits on the fly - one of them is: the Drive gadget will only report the PC0: drive when DmsVersion is TRB for the Professional DMS v2.02 Turbo by ParCon Software. For this version there also needs to be a PC keyword on the command-line plus the HD drive is handled differently to the PDX version... Unfortunately there is a hitch - as always. I managed to READ from PC0: to create a dms archive, but id didn't work the other way 'round - not BlitzDms's fault as I tried 2.02 from shell too - without success... As it was put forward that Prefs Save should be available at all times, I have replaced the MX gadget with a cycler for the DMS versions and it was joined by the Save gadget. Both the LoadPath/LoadName and also the SavePath/SaveName gadget pairs are now ghosted when not in use. Oh - and there is also a timer on the initial Unregistered requester - set to 20 seconds - actually this is 20 * 50 Ticks, so NTSC users will get it for a shorter time. If you look for seconds, they wrap, so you need to add the minutes*60 - but those wrap too, so you need to add them * 60. Then the Hours - and we get to midnight, so the days wrap. Ticks will give ticks at any time so it's much easier... And finally - your BlitzDms.res will need to be replaced as I had to change the BlitzDms.include file for some reason... Friday Feb 9th ------------------------ Damn, just overwrote a load of notes I made in this diary before I realised it when I put in Pauls new notes. Shit! The key writing bug was the only real major problem I fixed inbetween which needs redocumenting, and the fact that the author of XDMS has agreed to let us support it within BlitzDms. So if the end-user has LZX in their system then they'll be able to use XDMS as another compression option. I'll pick up the archive later on in the week. Still not finished the key stuff either. Bloody pain in the arse getting it right, and I've not got all the information in the keys I need yet. I need more free time. Fortunatly I don't have a playstation monopolising my time any more :-) Saturday Feb 10th --------------------------- Finally got the create key routine putting all the final data that the keys will need into them. Shit load of encrypted information which, if someone does manage to suss somehow, won't affect the global key creating program (which is what the keymaker is now going to end up being) as i can use a new encryption secondary string which means it needs reconverting all over again before details can be read. And even then the information is useless without knowing what checks are made on the key for other data in there, and where it is so a fake could be created. Need some tidying up now so that the routines which read in the keyfile to show the data are updated to the new format. Once I have the ability within the program to create and view a key totally safely and without any chance of a chance key fucking up (and this will need seriously testing as it has to be right the first time or there'll be one hell of a lot of hassle) then I can start work on the list creation routines for storing each key, so the registration numbers become valid, and the program updates them automatically to keep track and stop dupe numbers being used if I've been forgetfull in who's had a key. The program has to do everything for you as my previous key generator for backhatch did, so the minimum amount of info from me is needed. I can feel the finish approaching now, so I'm more enthusiastic again :-) Did some major stripping in the program to remove dupe routines so that the executable will be a lot smaller. There's still a lot of scope to compact it even more but I'll do that once the rest of it is in there as I need the crap within the source for reference at the moment so I can use it in stuff still to be written. Went through the code making all requestors and the title bars use information based on what program is currently in use. This way the window headers will display what program it is currently generating keys for rather than being hard coded for just BlitzDms. This information will come from a seperate config for each program which will be added later on, but I put the code to do this in now while I thought some of the harder routines through. Just discovered the checksum routine has now messed up. Fix it later I guess. Work in the morning :( Sunday 11-Feb-96 05:36:20 -------------------------------- Had nothing better to do than load up Blitz and start messing about with BlitzDms. After a while, I managed to get the window to work from inside the Statement - as usually, some undeclared variables... Once this was sorted, the font-selection routines also had to be put inside Functions so they can be called from anywhere as long as the parameters are available. Finally, after implementing the new MenuItem, the code for when that item is selected, had to be copied in. As I haven't looked into any of the special requesters yet - I know, lazy sod - I decided to leave that part to someone more familiar with them. I did test it with just one font which gets selected when the menu item is activated, it does work - and it defaults to system default font if too large or if it can not be found... Sunday feb 11th ------------------------- Major work this evening. Finally put the exact format of keys onto paper with all the info in so I could sort out the encryption routines and placing where the data will go. Each keyfile is 320 bytes long, and has the data in various places within, encrypted based on a configurable string, and it can be of variable lengths which are also stored and checked. It's going to be a tough job to crack it for sure. The show routine is now in place as the key format is sorted. It will prompt you if the key you show has a dodgy checksum, meaning it's been hex edited, so the same crc checks will go into the main blitzdms program to stop any fake keys working at all, apart from ones generated with the key maker. I think the checksum routines could be a little better, as I did manage to change one character to something else, and the checksum didn't report a difference. Certainly not possible to do any editing of a key at all anyway :-) I just have to put in the keylist stuff now and then I can have it creating keyfiles and pass them on. At the moment the keyfile number is hard coded for testing purposes. Now that the key creates, and reads okay and fail-safe (last thing I need is a key that doesn't work :( ) I've put the encryption of the text strings back into the generated keys. Now the text data such as name of registered owner, address etc, can't be read manually unless you can suss the encryption pattern, and work out where the strings are stored. I had thought of making it even tougher to read, as I have some new ideas now, but time is short, and the relic probably wants to have a look at it so he knows I am still doing some work every so often :-) Looks like I've got to put some font requestors into the main program now, as the relic has the functions sorted out at last. Monday Feb 12th ------------------------- Wow! I wasn't even trying that hard, and I've managed to tidy up a lot of messy code in the keymaker, and reduce the executable size from 74944 to 69504. That's only 5k, but it's only 5 minutes work concentrating on tidying up, removing dupe definition variables which weren't nescessary, and not thinking about adding bits which need to be done which has put me off cleaning this mess up until now. I'd recommend it to any programer :-) Damn! Lucky I had another fiddle with the thing again this strange hour of the morning. Just found a major bug in the checksum routine that could have caused a load of non-working keys to be created. All to do with using a variable for a for next loop as a .b in checking, and a .l in writing. Major fuck up, but luckilly I spotted the thing while optimizing, and saved a lot of potential hassle. We now have accurate checksums as well, I should have twigged something was wrong earlier as they didn't look right. Now just before I crash, now that it's working again after a serious butcher, it's time for one more huge snip to have a single procedure to display a key. I'm using a similar routine three times at the moment in the code, and that's sloppy. Also ripped out the tooltype functions this morning. Not nescessary if it's going to be global, as I'll add another gadget at a later date to load a seperate config for different keys. Worked great. The executable is now at 66780 compared to 74944. And it's got more features, and a lot of bugs removed from that version. The checking looks pretty much perfect now I have to humbly admit :-) I've done some more moving around of the code now in the hope of plastering more routines into seperate procedures so they can be used more than one time without duping it within the source. The save key option went this way although I can't see it being nescessary. I prefer to think of it as future expansion :) I'm now trying to make up a requestor function for passing flags to, so I can use that and save some bytes as there are at least 10 requestors that can pop up in the program at the moment if there are problems, and the entire routine can be handled with just the one function ideally, rather than the 10 seperate routines. Kind of like a library within a program. Fixed a potential problem with the keyfile save code. It didn't check for an error properly when saving, and didn't prompt you if there was a problem, even though it wouldn't fuck up. Now it'll have a requestor so you know what happened, and can fix the problem if it can't save a keyfile. The new requestor routine seems to work fine. Just a huge job converting all of them to use it. I have a feeling it might not save that much program size anyway, but I may as well finish what I started. The requestor stuff is now finished. It actually works out bigger :( I'll leave it as is though, as it's only a few bytes, and due to the way it works I have a feeling it will save program size in the long run. The time has now come to put in the keyfile list routines so that I can get individual keyfile numbers into generated keys. Once that's done, then this program is finished as far as BlitzDms key creation goes. I can update it to put in the extra features I want at my own pace after BlitzDms itself is finished and released. The option to view keyfile list is now working and will scan through the keyfiles in the list one at a time and display them, until it reaches the end, or you cancel it. It's not a very pretty way of doing it, but it's as good a way as any to check the hard work routines (such as the show key procedure) are working properly, before I later put bits in to use a listview or nicer display gui. It needs a bit more testing yet as, at the moment the actual keyfile list doesn't exist, so I'll come back to this part later. I kind of miss my requestor that said: "function not implemented yet, dude" now that this gadget actually does something for the first time :) The Version number has jumped a few positions now. It's near on finished so I've gone for 0.12 for now. By the time it reaches 0.50 it'll be 100% complete for generating keyfiles on any program, and V1.0 should be the ultimate key creating gui with all sorts of options from viewing different program keyfiles, to extracting keys from a list into a seperate file for people who lose their originals. Just an interesting bit of trivia while this bloody bbs finishes unpacking mail so it's safe to test the program again without the chance of guru's :) Who ever said V1.0 had to be the first release. With the keymaker, it'll be the last I suspect. Hmmmmm, time for coffee. True to form, the keylist now only stores two keys for some reason. The show keyfile list routine won't show more than one, and the creating keys routine now fucks up if it's any other details than my test stuff. In other words I've shafted the whole program up yet again. I do this every time I put in another routine, so I'll sort it out tommorow :-) Tuesday Feb 13th -------------------------- Wow! Never try to share a variable within a procedure which is called as a function with the variable name as a return result. Guru city for ages every time I tried to create a key after putting this shared variable in thinking it was an oversight, and might fix the bug where the sizes of address and email data were incorrect. Fixed the bug where it wouldn't let you abort viewing the keyfile list. Sloppy code as usual The whole thing is working now. Registration numbers are incrementing, and it's creating keys with correct details but every so often there is a corrupt key generated with bad details for address and email data which is usually shortened from what it should be, and means that the part of the key which stores the sizes for these two bits of info are wrong, and it means that even though the key is created correctly with the right data, the checksum reads incorrect as the sizing data is wrong, and the key will be flagged as a fake when viewed. I haven't managed to find a pattern for it where it always happens so it's a slow case of working through the entire source code to track down the dodgy variable sharing which I'm pretty sure it must be as the result of some obscure condition. I could just ignore it and just generate another keyfile for when this actually happens, but it's too risky when the keys will be used by other people and maybe it could lead to other problems when the BlitzDms program actually uses them. Hunting time again, it would seem :( Scratch the idea that it could have been data being less than double figures in length. Fixed that and the problem is still there. Fixed another quick routine I'd done with the make key routine. If I clicked on abort to not save the generated keyfile, then it would still add it to the list of keys. Looks like I've been sloppy in a lot of the requestor return codes so I'd better check them now while I try and suss this bloody other bug. Fixed another bug with the make key routine where it would save a blank line in the keyfile list if you aborted in the middle of generating a key, and not while it displayed the key. Potentially dangerous stuff. Having no option to abort the keylist creation was a bit silly considering it prompts you that there wasn't one found in the first place. I've put it into the code now just in case the path was wrong or something, or I shuffled the place where the keys are stored and didn't change the source code accordingly. Shouldn't matter once the keymaker has its own config file anyway, but it's best to be thorough now. Fixed a bug with the Date and Time information not being shared which I broke while trying to find this other bug. Same problem with saved keyfiles not adding the username extension. Argh! Bloody not saving any info in the keylist now. Fixed. Fixed up the date and time encoding into the key. It was only fetching the info when the program was run, and not when a key was generated, so if you generated 10 keys in one go, they would all have the same datestamp info. Also fixed a few dupe chars in the keyfile as they stood out as pointers to possible data worth playing with by the agnostic :) It's now really bloody rare that a key comes up which has fucked data. If it does then I can just abort and generate one again, and I just can't seem to suss where the problem actually is as it's such a random occurence. It's safe enough to use the program anyway for generating keys as the same routine that checks a key in the keymaker source code will be used to check the keyfile in the BlitzDms source so it's not really a problem as I know when a corrupt key has been generated. If I fix the bug in future then, due to the way the program works, it won't affect any keys created by it anyway. Time to leave the KeyMaker I suspect and get on with the main program again. The Key Checking code will go into BlitzDms and other such checks right after I confer with Paul and let him check the program out as well. In the mean time it's time to work on the doc file so I can let the BetaTesters at it. Tuesday 13-Feb-96 08:14:27 -------------------------------- Seeing that BlitzDms isn't in my court, but instead I have a new .doc file plus a new Keymaker.bb2, there is plenty of stuff to get on with. Nice. :) But first a small suggestion as far as the to-do list is concerned: there are so-called check-menuitems available which can either have a checkmark next to them or not. Very similar to checkboxes, they are ideal for certain menu-items such as wether a Prompt is set to YES or NO... With this out of the way, let me first list the changes I made to the .doc file - apart from the few syntactical or spelling mistakes: 1. When a selected PubScreen is not available, BlitzDms does NOT fall back to Workbench, this is due to Blitz not returning any values. If the SetErr command were missing, there would be a very strange GURU. 2. Added all explanations to the tooltype variables that were missing. 3. Shareware - added the line about a need for a users PGP Public key when delivery of a keyfile via e-mail is requested. When crashing the keyfile to a BBS the risk of it falling into greedy paws is lessened. 4. Address of Paul Juhasz - I must fix into Barnet or change the entry. :) There is a further query - presently not ALL of the DMS options are fully supported: 1. The Repack command, available in all versions is not supported. 2. DMS202 has support for .FMS files (self-extracting) which are not supported by BlitzDms 3. The TRACK, ENCRYPT and NOZERO options are not supported. After dealing with the .doc and reading the .diary, I had a better idea as to how the KeyMaker should work, so I started with a good look at the source. In less than 5 minutes of browsing I found more bugs than I expected. Functions usually need a Function Return command, it won't do to just alter the parameter that was passed in. One very obviously glaring problem was the confusion between some DefType and some SHARED variables in functions. I have also given parameters to some functions instead of using SHARED vars, which won't have much influence on either program size nor speed (it's not a flight-sim) but does make the code a lot easier to read and debug. The encryption string was limited to lower-case letters only, why not have all of them, plus space, numerics and some special chars as well? I know this will change the way the program works and previously made keys won't be correct any more, but we want a really good KeyMaker, don't we...? After having made these changes I generated over a hundred keys, most of them using the test-details, but I typed in at least 20 original ones. Not once did I manage to get a fake key or any other problems. The doc file has been brought up to date with the new features of BlitzDms. It will need to be added to once the program is finished, but the job will be a lot quicker now that the grunt work has been done. I'll convert the file to AmigaGuide format then as well. Started working on BlitzDms again. Some minor cosmetics have been done on the about requestor. The information displayed is different depending on wether the program is registered or not. It will display the key details if it is, and the shareware note otherwise. Removed the Save config option from the menus. Made nescessary changes in the include and generated a new resident file. There is now an option to select if prompts should be on or off in the menu instead. It works properly, but it needs some visual confirmation to show it has changed the flag, so I'll have a hack at outputting a message into the status box for that next. YES! I love Paul's style of programing. After some faffling around due to me not reading his source properly, I discover that he has a global update routine to change the status line anyway dependant on a flag. So the prompt selection option just sets a constant for the condition and I just add it to the list of messages that are read in and we have visual confirmation on the status line when you either select the menu option for prompts on or off, or press the hot key (P). I love it when life is made easier for me :) Wednesday feb 14th ---------------------------- After managing to change a menu option yesterday in someone else's code I felt brave enough to throw a new one in, and worked out how the menu's worked in the process. I've already put into the docs that BlitzDms will support Kcon for those who have it installed, so I've put the feature in and added the new flags to the include and .res file. Works great ;) Updated the documentation to revise the Kcon usage in the BlitzDms doc file, and document the menu commands as I forgot them last time :) Made Kcon support a registered option only, and fixed a small bug where it was reading the tooltype for kcon wrong and automatically had it switched off until you changed it manually. Now it uses the configured option properly. Did some cosmetic on the Prompt requestor which is displayed when you have confirmation prompts on. It looked messy until now as it was meant to be only for a test routine originally. Requestors don't display the path information anymore, even though it knows them. There's no need and the requestors can be much neater as a result, and less chance of the strings being too long to display all the info in the gadget, as you might not have the abort button available then, and it'd look as messy as fuck. Spotted a bug in the about requestor keyfile number display. Hmmm looks like key 99999 isn't favoured very much :) I've upgraded to V0.87 for now. As good a number as any. Once Paul confirms the key system is okay, and we have the APPwindow stuff in and I've put in the key check routines, then it's off to the testers, and we're ready for release :-) Now I've done some more work this evening we're on V0.89 :) After taking a good look at XDMS I've started working on updating the include file for some new constants we'll need, and, after a power cut losing me an hours work, normal service is resumed, and it's the long hard task of getting into the source code and putting all the new bits in within the current gui limitations, and extra menu options for now until Paul has a look and decides if he wants to extend the gui a bit. I'm considering using slider gadgets within the window as they can be used for Xdms and normal DMS mode to choose start and end tracks to work with. It'll be a lot more effort into the program though, and could lose us a few days now that we're almost there. Using the status line as a visual confirmation that options have been changed I've plugged into the menus extended commands for choosing the path to the xdms binaries (using a directory requestor) and extended the commpression gadget to allow an Xdms option. Also in is an option to choose the xdms mode where ALL means it does every track, and DOS means it'll only compress valid amiga blocks which is handy for dos disks as it means the only information stored will be what's code, and no empty blocks. There's also an option to compress some of the blocks with the SOME argument on xdms, but I've not put any support for that in yet as it'll need a slider gadget for start and end as detailed in the previous paragraph. Mucho debugging later and all the new options work, and save and load correct into the config tooltypes. The menu strip is a bit long now so I may have a crack at putting the xdms options into a seperate menu strip, but that's dependant on wether Paul wants to extend the gui and put the options on there or not. It's usable just as easy from the menu's anyway as I've put hot keys onto all of them. Fixed up the return codes from the xdms options being used. Wrong messages were being displayed and I didn't notice at first. Now it works great. All I need is to put in the parts which use Xdms in the console routines and that part of the program should be finished, providing no changes are needed. The Start and End track options would be nice for both dms and xdms though so I'm pretty sure they'll end up going in as well. Sunday February 25th ------------------------------ Now that we've sorted out who should be doing what in the program, I've put together another gui for a prefs window for BlitzDms which Paul has added to the main program, so we've been able to move some of the gadgets to the new window which comes up over the old, and make the thing look a lot tidier. Today I've added in the routines to read a keyfile if it exists and make BlitzDms run according to if it is registered or not. The keymaker has been finished a few days ago and extensively checked by both of us without any problems whatsoever, so it was safe to update the main program so it works according to wether a valid keyfile is in use or not. Adjusted the about requestor to put in the registration details if applicable, and put a couple of new functions in to get the current system date so checks can be made for temporary keys and BlitzDms react accordingly if they have expired. The actual checks still need to be written yet, but the information is there ready to use now. BlitzDms will now also support password encryption, use of specified tracks for both Xdms and normal dms operation, and the Xdms configuration stuff is now included on the gui rather than horrible menu options that I'd put in. Kcon support will still be used but I'm not sure how it can be done as yet as most people mount Kcon: as an alternative to Con: anyway so I'm not sure if a setting is actually needed for this as BlitzDms will react accodingly anyway. Having it as an option for registered only seems pointless now since it can be bypassed via the above method anyway. Also available will be the text banner options to include one in a dms file, or surpress them when undms'ing a file to disk. Hopefully that means that BlitzDms now supports all the options available for the dms versions we cater for in the program. Thursday 29th February ---------------------- A lot more work on the keyfile routine in the main program. Pulled out a few suspect bugs which were due to bad indenting on my part meaning return codes wouldn't actually be reported. Threw in the date stuff so that BlitzDms will be able to compare the date in the keyfile to the current date and restrict the program if it's a beta key that's been in use a certain amount of days. Still have a bit of work to do with the actual converting date to days code but it's all in ready for fine-tuning. Changed the icon reading in routine which I'd documented some work needing done in the source code and never got around to fixing the problem which could have led to the program not working properly even if it did or didn't find the icon sometimes. Pulled out the requestor prompting you if it didn't find it now, as it's reported in the status line anyway, and blitzdms will always have default configuration settings it will use so no harm can be done. Went through my source code documenting changes with marks so that Phineas can move the routines across when he gets it. He's working on other routines in the program and we're safe doing this as we know what the other is up to. Sunday 3rd March ---------------- Phineas has done a heap of work on the program since I last had his version. Now that he's incorporated all the keyfile stuff that I've done into his code we have one whole program again. Now we have Track sliders, option to use NoZero which was the only dms feature missing until now that we hadn't supported, and the new prefs window and all the options now function. It looks funky as well as the custom shape for the gui is working on both windows and gives the window that classy look. Putting in the dms options into the command line routines (whatever ones are left) is the next thing to do, and sorting out a minor cycle gadget bug which doesn't happen on my machine but does on his. Then it's just the appwindow stuff for dropping icons onto the gui and we're ready for final beta-testing. Fuck if it doesn't look great already. You can do anything with BlitzDms now :-) BlitzDms now works dependent on what type of key is in use. Thanks to Paul fixing the date working routine to get number of days between two dates (I had a load of problem with this) then a temporary keyfile will last 14 days from when it is created, before BlitzDms will no longer work as a registered program. Anyone wanting to test it for us can now do so if we like them, but their keys will be temporary until we've had some feedback and reports from them. If they're helpfull then we'll give them a full keyfile when we release the full program. Tuesday 5th March ----------------- Did some more work on the Keymaker tonight. Changed the encryption strings to allow for a couple of extra characters as the date and time information for the keys needed to be encrypted as well, and it was plainly visible in the keys if not done. Updated the program to use the new changes and added the new bits into BlitzDms itself so new keys will work with the program. Changed a lot of the about window information to show the configured encryption string, rightly credit Paul as well as myself for the hard graft in creating it, and use reqtools requestors rather than the old versions which needed two gadgets all the time. Okay prompts are all we need with requestors like this. Added in some more error prompts if it can't either load or save the key. Discovered what was probably causing the compiled program to clash with other gui's on my system if it was running. Using gadget 0 upwards instead of 50 onwards like the blitz docs recommend. Updated it to use constants for the gadget numbers instead so global changes can be made much easier in future. The keymaker now also has options to extract a keyfile from the list when using the show list function so replacements can be quickly taken out of the list if the user has corrupted theirs. It saves to the configured path with the username extension as normal. Most handy for test purposes as well :) Also means Paul can send a replacment as well as me if someone has a problem. And finally mucho tidying up of the keymaker source code. Seems to run a little smoother now, but that's probably wishfull thinking on my part :) Testing of the keys was done rather thoroughly this evening without any problems surfacing at all. We're about to send it out as beta testing now so this needed serious checking. Sunday 10th March ----------------- BlitzDms v0.97b was released to the beta testers on Thursday. Bug reports coming back have highlighted a few little quirks which need fixing, nothing major thankfully, and most of them were problems with the default config I left in the icon which was specific for my system. Next beta will have no tooltypes defined in the icon so that configuration is done by the user when he first runs it. Today I've worked through stripping some of the executable size by using rtezreq tools requestors instead of the blitz defaults, and converting all the old code which forced two buttons at least to have just an "_Ok..." gadget, such as the initial delay requestor, and the about window which didn't need any others. It meant modifying all three seperate source code files so hopefully Paul isn't working on any of them himself at this time. I'm hoping to just be working on the actual dms routines now that this is done, rather than any more gui stuff (apart from fixing bugs if possible) so that if we have clashed, then he'll be able to rip my bits out easilly enough. The new requestors look so much nicer, and are centered as well as having hot keys for them now which is important. Kcon: support has been changed to just use Kcon instead of Con if you don't have it mounted as a Con replacement, like me. Added option to Save prefs in the quit confirmation requester. Sunday 23rd March ----------------- Kinda lost the plot with this diary until now due to working on the program and other stuff bbs related as well, and it's so near finish now, that I couldn't be arsed to carry on updating here when more important tasks needed work. I'll have to keep it simple with regards to what's been done from now on if this is ever to look like a lowdown on the whole blitzdms development project. Appicon support is in now. Dropping Icons onto the window configures in the appropriate manner regarding load or save paths and kicks dms straight into action. This way multiple icons can be thrown in at one go and it'll do the buisness while you nip off elsewhere. Well that's the theory anyway but it's Phineas playing with this stuff as I'm busy elsewhere. The gui is radically changed now to use GTMX gadgets for the dms mode. Other gadgets have been moved around accordingly to make it look nicer. Does too. Kcon support is still there for weirdo's like me who are using it as a seperate device to Con: Phineas is looking into having blitzdms in touch with the dms executables as they work so we can have progress bars etc, and know when something goes wrong. The guide is almost complete. Repack and Append modes are added to what Bdms will let you do if the dms version supports it. NoVal and NoZero flags have been added for setting the no validate disk mode and supress bootblock display. Double density and high density drives are now supported if the executable of dms allows it. Encryption of dms archives and Banner related tools are also working now. Xdms is nearly there. How long have I been saying that? :-) A lot of bug squishing too based on reports from the 0.97b beta version that did the rounds. We're on V1.0b and ready to send out a last minute beta to get it checked. End for now.