Winwad version 2.0 source code - Doomworld /idgames database frontend

Title:	Winwad version 2.0 source code
Filename:	utils/wad_tools/winwad2s.zip
Size:	74.2 KB
Date:	05/28/00
Author:	John "Snowman" Gaughan
Description:	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.)
Credits:
Base:
Build time:
Editor(s) used:
Bugs:
Rating:	(1 vote)

Download mirrors:

/idgames protocol:

idgames://10715

View winwad2s.txt

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

mong