Source code to Winwad version 2.0, never released. I am releasing it here because I am moving off to join the military and DoomNation is (permanently?) down. There are no binaries, only source code released under the GPL (license text included.) Have fun. John "Snowman" Gaughan ============================================================ Winwad - 2.0 BETA 1 author: John Gaughan e-mail: snowman@apk.net web: http://junior.apk.net/~snowman/ http://www.doomnation.com/winwad/index.shtml Winwad is a general-purpose Doom wad editor for Windows 95, 98, and NT. Winwad and its accompanying libraries are freeware, and are provided as-is. By using Winwad or its libraries (the software), you understand that the author is not responsible for any damages the software may inflict on your computer. Although the software is not designed to harm your computer, bugs may be present that can possibly damage your computer. Visit Winwad's home on the web: http://www.doomnation.com/winwad/index.shtml Here you will find links to the latest version, and the latest information on the program. The author may be reached at the e-mail address at the top of this file. Winwad is a C++ program developed in Microsoft Visual C++ version 6.0. ============================================================ Winwad Change Log ============================================================ Version 2.0 BETA 1 - 1. Rewritten almost completely from scratch using MFC. ============================================================ Version 1.01 - 12:00 am EST, Thursday, December 9, 1999 1. Tried fixing the palette display, still doesn't work, but now it appears in black. I am getting closer... 2. Miscellaneous little code fixes here and there. Nothing too major, hence the .01 version increment. ============================================================ Version 1.0 - 1. Fixed some tiny bugs and problems, nothing major is left. 2. Added ability to load a wad from the command line. Just drag and drop a wad onto Winwad's shortcut or EXE and it will start up and open it. Alternatively, you can specify it on the command line: "winwad.exe c:\path\wadfile.wad" ============================================================ Version 0.2 - 3:45 pm EST, Saturday, September 18, 1999 1. The font is one point size bigger, and easier to read. 2. All child windows are now sizable. The controls dynamically change size, even when maximized. 3. One potential memory error was fixed in the function that parses data for the hexadecimal preview window. An array index error could have occurred, possibly causing an access violation (but probably not). 4. Performance has been improved slightly. ============================================================ Version 0.1 - 11:15 pm EST, Monday, September 13, 1999 1. The edit menu and everything on it is completely functional. Winwad is officially beta, and will move from build numbers to an actual version number system. 2. Clipboard functions ONLY work within Winwad. You can't copy between Winwad and another application, not even another running copy of Winwad. This may be changed in the future, the clipboard library is set up to allow shared memory with another application but the code and implementation just isn't there. ============================================================ Build 017 - 2:30 am EST, Monday, September 13, 1999 1. Changed internal wad handling to avoid memory leaks. 2. Implemented parts of the edit menu. Cut, Copy, Paste, and import do not work, the rest of the functions do. Import sort-of works, but is disabled in this release. ============================================================ Build 016 - 1:45 pm EST, Saturday, September 11, 1999 1. Added code to change cursor to hourglass while loading and saving wad files. Large files can take a while to handle, and the cursor was not reflecting this. 2. Added code to display wad entry information in the static text windows. Fixed text windows to display information. 3. Hex preview parsing works, but formatting needs to be improved. Getting the right font the right size is proving to be difficult. ============================================================ Build 015 - 1:50 am, Friday, September 10, 1999 1. Changed directory window to scale correctly based on font size. The font it uses is "fixedsys 10," a system raster font included with Windows no matter what. Now I can easily change the number of characters for the width of various controls and have the computer figure out all the details on its own. It is a pain to get the character pixel dimensions - create a logical font, get a device context for the only thing I have at that point - the window itself, use this to GetTextMetrics, then grab the info from there. I can't just grab the dimensions with a font handle. Blech. 2. Added more menu options for editing, added more keyboard accelerators, noted old and new accelerators on the menus. ============================================================ Build 014 - 2:30 pm, Thursday, September 9, 1999 1. Fixed the memory leak associated with closing a file. The problem was that each DLL/EXE had its own memory heap: freeing memory allocated in one module from another caused an error because the memory was not a part of that module's heap, so an access violation would occur, or nothing would happen. The solution was to link against a shared DLL version of the C runtime library. This also reduced the file sizes of the program by a shitload. 2. Winwad is closer to the beta stage... as soon as basic wad editing is implemented to the point where it can be slightly useful, it will be beta. ============================================================ Build 013 - 1:30 am, Wednesday, September 8, 1999 1. Switched to structures instead of classes. Loading of wad files now works, as does the directory listing. Editing of any kind does not function. Saving is broken, it saves the correct length file but all entries have their bytes set to 0xCD. Closing a file after opening it (which you have to do to exit) causes a memory violation in debug mode, and testing indicates no error appears in release mode. Most likely, Windows is quietly allowing Winwad to corrupt its own memory. 2. Behavior is inconsistent between Debug and Release configurations. There may be an option in the compiler to change memory handling in some way, I will check this out tomorrow. ============================================================ Build 012 - 3:30 pm, Saturday, September 4, 1999 1. Fixed a nasty memory error in the wad class. Instead of storing wadentry objects, it now stores pointers to the objects. This fixed an error in the load routine, but to keep the wadentries alive it will be necessary to go back to storing the actual entries in the wad class vector. More work with dynamic memory allocation is necessary. ============================================================ Build 011 - 6:00 pm, Wednesday, September 1, 1999 1. Fixed the LAST bug in the IWAD selection dialog. I was sending LB_ADDSTRING instead of LB_INSERTSTRING to the list box, and that screwed everything up. 2. Wad directory window now has controls and a set initial size. Code is in place to display data in the list, but the file handling code needs to be worked on first. ============================================================ Build 010 - 1:45 pm, Wednesday, September 1, 1999 1. Tweaked the logo a bit more 2. Fixed the IWAD selection dialog so it now works correctly 3. Still have an uninitialized string or two somewhere 4. Implemented the Open IWAD common dialog box ============================================================ Build 009 - 11:50 pm, Monday, August 30, 1999 Sporq supplied a logo. It may be refined or edited a tiny bit more, especially the icon versions, but I think it is basically what I am looking for. The IWAD Selection dialog is a bit larger, and actually works now. The "Add" button is not functional, but should be in the next build. Also in the next build the Wad Directory window should have something in it. After that, logically, the file handling will be debugged so it doesn't crash. I really need to watch that malloc() function... ============================================================ Build 008 - 8:00 pm, Monday, August 30, 1999 Fixed one little menu error. File handling is still broken, and disabled. Debugging mode shows that there is a memory violation in the file library. Most likely this is caused by an invalid index with a dynamically allocated array pointer. INI file handling is in place and working correctly. There are four methods -- two that initialize/free dynamic memory, and two that load/save INI information into the Global structure. These are called when the frame window is created and destroyed. The INI file is saved to wherever the program is started from: i.e. c:\projects\winwad\debug or c:\winwad. More miscellaneous bug fixes. Several pointers were being used before assigned to memory addresses, which caused an extremely nasty crash on startup that was difficult to track down. Nested structures with pointers can be confusing at times, in another error in the program: a.b->c = &d; a.b[i].c = &d; Both of these would compile because in the first case the compiler considered "b" a pointer since it is an array ("&array[0]" is equivalent to "array"), but it was not producing expected results and when I stored data in that array of structures, and threw everything off. The "Choose IWad" dialog needs some work. Basically, you choose a WAD file to edit, and you open it against an IWAD. That way you can open a WAD with only a TEXTURE1 resource, and it will look in the selected IWAD for the PNAMES and actual patch data. Or, you can choose to not open it against any IWAD, such as if you want to create your own IWAD. Anyway, the dialog comes up and gives the choice of IWADs, but the conditionals that actually change the current IWAD do not work. I am seriously wondering what the problem is, there are only about 20 lines of code and most of those are either SendMessage() or if(). I just may start this over from scratch and make a new dialog window procedure. You do not select a game to edit, but an IWAD. The game will eventually extract the palette from the PLAYPAL entry and won't really have a need for any game-specific handling. This will help for people creating Doom megawads with all new resources. You get 32 different IWADs to choose from, which should be more than enough. ============================================================ Build 007 - 2:30 am, Monday, August 30, 1999 Finished menu handling of enabled items for now. Program correctly enables items, shows message boxes if a file is not saved or is closing down, etc. and only allows one wad directory at a time. File handling is broken. Currently, any time the file library tries to load or save a wad, the program crashes with a memory error. Apparently there is a wild pointer in there somewhere, and when it tries to dynamically allocate memory, it tries to overwrite the kernel or something and Windows shuts it down. I will have to debug the file library before I uncomment the references in the EXE and distribute it. There is NO WAY the program as built right now can even TRY to touch an actual file, no matter how realistic those Open/Save As dialog boxes look... I added another layer of abstraction between the program and the disk file. Now the frame window procedure (basically handles the menu items common to all MDI children) calls another function in a separate module, which in turn messes around with the OPENFILENAME structure and the common dialog boxes. It does error processing, i.e. "File Not Found," etc, and stores the file name in the "Global" structure. It returns true or false for whether or not the operation succeeded -- so I have even more variables to track just to make sure the damn file opened or saved correctly. I added more comments to the code. Now, every line of code has a comment explaining what it does, no matter how basic it is. ============================================================ Build 006 - 1:02 am, Sunday, August 29, 1999 Added more comments to the source code, rearranged global structure for ease of reading, fixed a few minor errors that wound up not fixing anything noticable. #EOF