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.)
John "Snowman" Gaughan
Winwad - 2.0 BETA 1
author: John Gaughan
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
Visit Winwad's home on the web:
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++
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
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
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,
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" 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
I added more comments to the code. Now, every line of code
has a comment explaining what it does, no matter how basic
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.