================================================================================
Doom (Shareware) Installer for Windows x64
================================================================================
v1.00.00
- Pending testing and community feedback.
- Pending testing under Windows Vista Retail (No Service Packs)
================================================================================
v0.96.xx
- Working on them...
+ Changed name of class & file to match: 'OriginalCurrentWorkingDirectory'
+ Locked the Buttons
+ Disabled the [Play Doom Using the Source Port] button. There is no code behind it yet anyway!
- Checked buttons for ToolTips, couldn't see the Property for it. (Done it before, might have moved on me, or not be applicable to Buttons (anymore?)).
+ .....
+ ....
+ ...
+ ..
+ .
================================================================================
v0.95.60
+ Fixed some stuff up, improved the code around the Unzip, etc.
+ Added a 'StartingCurrentWorkingDirectory' object, for future use.
+ Few other minor improvements.
* Created a 'bugs' folder, and added some exceptions and MessageLog.txt to it!
================================================================================
v0.95.25
+ Previous idea was madness, Shell32.Shell() and the interfaces and interop required are barely documented. (Maybe they were once, but Microsoft has broken 90% of their MSDN links of days long gone. The Wine doco isn't complete for it either, as I don't imagine Wine care much about Shell32.dll being used for Zipfldr.dll in ways that are unsupported even by historical Microsoft).
+ Trying out the Ionic.Zip.dll from the DotNetZip 'Project' on codeplex.com
- The ZIP I am extracting contains a folder, and I'm not currently cleaning up the destination folder in a manner similar to DELTREE /Y . or RD . /S (yet).
================================================================================
v0.95.00
+ Added COM for the Win32 Shell Unzip, as the Windows shell supports ZIP folders via zipfldr.dll and possibly other methods. (Bashar Yassin Tahir, a Student from Iraq has published how simple this is). Using Microsoft Shell Controls and Automation, v1.0, C:\Windows\SysWOW64\shell32.dll).
- As such I want to test it under Vista x86 (32-bit) as it is a different OS and the 32-bit version should not have the WOW64 folders.
- That said the archive downloaded is a Win.x64 Console Self-Extracting Executable RAR archive.
================================================================================
v0.89.75
+ Set ticks1 after each button click, not within Download(pKVP) as before.
================================================================================
v0.89.55
+ Added time (in sec) as well as performance (bytes/sec)
+ Note here that tick1 was still used for the performance calculation from ages ago.
================================================================================
v89.51
+ PrBoom download now gets the correct file.
- The 'extract' for PrBoom just opens the .ZIP file in the default application!
+ File Sizes added as they are queued, using integer literals.
- File sizes are not checked upon download completion, then performance calculated from this. (Would save having to manually find several file sizes in bytes). There should be a way to do this using a sort of call back or Event Handler or something...
================================================================================
v0.89.00
- "This was way harder and more involved than I was expecting. It was raining and learnt a lot in a weekend."
+ Another 90 minutes of development, maybe 30 minutes of that was testing.
+ The average download speed (bytes/sec) is displayed after the queue is empty!
+ PrBoom added as a Source Port (no selection as only one so far).
+ Messages made more human (e.g. "The downloads that had been started have now completed. [OK]." & "Download queue has stuff in it and no downloads are currently in progress so I'd better get off my ass...").
- After the downloaded archives are moved and extracted, they are not deleted (wastes some drive space).
- If there are partial downloads the application logic *might* screw up a little bit.
- If the app is just 'run' from the ZIP, then it will download to a temporary folder. (If it could detect this and install to C:\GAMES\ instead that would be better).
- For various reasons it is possible for the download to stall.
- The PrBoom Button appears to download the wrong file!
================================================================================
v0.84.01
+ Under Development now until say 5:00PM AEDT
+ 36 minutes (4:34 PM 10/11/2013)
+ Downloads work OK, CurrentDirectory can be changed, and files extract.
+ Still, it'll need a Source Port to be able to run under Windows x64 (64-bit).
================================================================================
v0.83.00
+ textBox1.ScrollToCaret(); added to timer tick (every 125ms loop) as test.
- .ScrollToCaret() would only work if we could set the caret location to the end of the message log, but we cannot. I'll look into it later as it's not a high priority for what the app is meant to do.
================================================================================
v0.82.00
+ Set the minimum and maximum window size to 640 x 300
+ Added TITLE__ constant, used it on the Initialized message.
+ Changed message about the download queue not being empty to "Download queue count is greater than zero and no downloads are currently in progress so I'd better get off my ass..." and added carriage return + new line to the start of that line so it stands out a little more.
- The multiline text box does not automatically scroll down as text is added to it!
================================================================================
v0.81.00
+ OK, the messages appear when the QUEUE is EMPTY, not when the actual download is complete!
+ We can work with this (Async Downloads can be a bit tricky).
+ 90 minutes of development & debugging only to realise that the message appears when QUEUE.COUNT == 0, not when the actual download is complete.
- When the FIFO queue was empty the message was displayed, but the last async download had not completed yet. + There was some confusion as to if it was downloading just the two queued files, or three (e.g. one of them twice), or even four (the pair twice for some reason).
+ This has been fixed now, but refactoring some code, and calling it from Download completed Event Handler. [OK].
================================================================================
v0.80.00
+ Added a multi line text box, so the application logs what it does
================================================================================
v0.74.00
- Observed that it is possible to keep clicking [Download] to keep Queuing the same pair of files to be downloaded again and again... this isn't desirable
+ Disabled the [Download] button just after it is clicked
+ Re-enabled it when (mDownloadsStartedPendingComletion && mDownloadQueue.Count == 0) is true.
- Even doing this, it appears to keep downloading a file after it is complete!?
================================================================================
v0.73.00
- Added mDownloadsStartedPendingComletion, to track when both it and mDownloads.Count are false/0 so a message is only displayed ONCE when ALL queued downloads have completed, and not before any downloads have started, or every 125ms
================================================================================
v0.72.00
- Tries to download to DOWNLOAD_DIR constant
- QUEUE_CAPACITY constant added
+ 8 minutes development
+ 7 minutes testing
================================================================================
New
- I'll make a note to make 'I have the full version, let me play it' as a feature request.
- If the download stalls it does not automatically start over (or resume if possible), check every 6 seconds that at least 'some' data has been received.
v0.71.00
- Added mDownloadInProgress, and rejigged some of the code so that only one download is performed at a time. (People usually complain about the opposite, but trust me, that's not want we want when sharing a progress bar this early in the game!).
+ Add another 15 to the development time
+ Add another 5 minutes to testing time
+ Add 2-5 minutes to admin (documentation) time
================================================================================
v0.70.00
Currently it's either crazy, or crazy awesome.
I think it's a bit crazy as the progress meter is 'shared' by the two queued downloads.
This will be getting improved over time.
So far 60 minutes of development work, 12 minutes of which was testing, and about 4 minutes on the Internet have gone into this.
- The GUI took about 8 minutes.
- The code has only taken about 36 minutes so far.
================================================================================
Internet sources:
- http://www.csharp-examples.net/download-files/
Download URLs to test:
- http://downloads.sourceforge.net/project/dooms-19-winx64/source/Doom%20%28Shareware%29%20Installer%20for%20Windows%20x64.zip?r=http%3A%2F%2Fsourceforge.net%2Fprojects%2Fdooms-19-winx64%2F%3Fsource%3Ddirectory&ts=1383992675&use_mirror=aarnet
- http://sourceforge.net/projects/dooms-19-winx64/files/latest/download?source=directory
- Any more?
================================================================================
Download Latest Version
Get DOOM in 60 seconds (431.2 kB)
