EasyWAD DOS Based Frontend

[40oz]

I recently bought a copy of Demon Gate, a compilation of 666 doom wads for $0.21 on Amazon. It also comes with a program called EasyWAD, which is a dos-based program that lets you navigate through your wads directory, and tells you what maps the PWAD replaces (great for 1994 wads that take place on random mapslots) and if it has new sounds, music, graphics etc.

I can't seem to get it to work though. I'm having a bit of trouble interpreting how the easywad.cfg works, I'm also concerned with the possibility of it not working because it doesn't think I have Doom. I'm pretty sure it's looking in the directory to find DOOM.EXE, in which all my Doom and Doom 2 installation CDs create Doom95. Would it be possible to trick EasyWAD into thinking I have DOOM.EXE by say, renaming a sourceport's exe to DOOM.EXE? would that create conflicts with the functionality of the sourceport?

[Justince]

r_init: getpostnumberforname: post not found!

Edited July 28, 2017 by Justince

[hex11]

Amazingly, the author's homepage is still around:
http://void.thunderteam.org/index.html

It looks like the EasyWad ZIP files also have source code (plain old ANSI C in one file, can probably be built with DJGPP, unless you happen to have the Borland compiler or something). So it should be possible to make this work somehow or another...

I really like his "Doom 3" download link, and his answer to the resulting C&D letter. ;)

[Maes]

The code to the utility is the weirdest C I ever saw. A single file, it has a certain Turbo Pascal feeling to it O_o

[hex11]

Did you read his "rules to become a good programmer"?
http://void.thunderteam.org/goodprog.html

[Maes]

Most aren't even his, just old usenet alt.prog.* smartassery.

[fraggle]

That is a pretty odd coding style. BTW, you won't be able to compile this in DJGPP - this is 16-bit code, it only supports 32-bit code.

[hex11]

Silly thought: maybe he used one of those "Pascal to C" converters?

[fraggle]

It looks too carefully formatted for that to be the case. Some people do just have weird coding styles. Check out the source code to the original bourne shell and you'll see this is fairly tame.

[Maes]

Deja-vu...

The Secret to Better C

#include "pascal.h"

The sh example reminded me of some advanced BASIC or FORTH dialect (those PROC statements...)

I find it hard to believe that more than one programmer thought that it would be more productive to mask C so that it mimics Perl/Pascal/Fortran/Forth/Basic/whatever they considered "superior" rather than learning to code in straight C. I mean, the effort to get such a system of facades/thin layers working properly requires learning the target language to a degree that would defeat the need to use such a facade in the first place.

Edit: what's more scary about the shell source code is that those Basic-like IF, THEN etc. statements IN BIG CAPITAL LETTERS don't seem to be defined anywhere, not even in the hellish defs.h. So that code could only be compiled by a fucked up/nonstandars compiler or there are more includes to do :-S

Edit: nm, they are in mac.h. The guy is credited with starting the International Obfuscated C Code Contest. No. Fucking. Kidding.

On the bright side, Doom's source code could have been MUCH, MUCH worse....

[fraggle]

Maes said:

I find it hard to believe that more than one programmer thought that it would be more productive to mask C so that it mimics Perl/Pascal/Fortran/Forth/Basic/whatever they considered "superior" rather than learning to code in straight C.

On the contrary: as I understand it, one of the original reasons for having a preprocessor as part of the language was to allow hacks like this, so that programmers used to using other languages could transition to C more smoothly.

[GreyGhost]

40oz said:

I can't seem to get it to work though.

Doesn't work for me either and I have the DOS executables. If you're determined to use a DOS frontend, I'd suggest DoomShell which has a nice graphical interface and should run fine under DOSBox. I'm using DoomShell 5 from the 3D Game Alchemy CD.

[Maes]

fraggle said:

On the contrary: as I understand it, one of the original reasons for having a preprocessor as part of the language was to allow hacks like this, so that programmers used to using other languages could transition to C more smoothly.

That would make sense if the one making the hacks was also not the one having to use them: e.g. a C lab teacher that seeks to gradually introduce C to students with some previous exposure to Pascal.

But whenever such "enhancements" pop up it usually turns out that they are one-time hacks for exclusive, personal use by the programmers that created them, so once again I ask: if they were so skilled as to learn to abuse C's preprocessor to such a degree, and the hacks were for their personal use only, why didn't they simply code the damn thing in straight C in the first place?

And before someone asks...I place the line between "convenience macro-ing" and fucking up the language at the point when you start replacing basic operands, keywords and even the God-damn brackets.

[hex11]

I think it looks okay. The uppercase IF/THEN/ELSE/FI stuff stands out very well from the rest, whereas in C (and Perl, etc.) you end up with a lot of {( )} spam that can be hard to visually parse at times, esp. if you've been coding for hours or you're not completely awake. Plus, he probably didn't have a fancy text editor with syntax-highlighting, brace-matching, etc.

And if someone doesn't like it, it's not terribly hard to search & replace all his define's back to the original C syntax.

[Maes]

So it REALLY is a "Better C"? :-p

[printz]

hex11 said:

I think it looks okay. The uppercase IF/THEN/ELSE/FI stuff stands out very well from the rest, whereas in C (and Perl, etc.) you end up with a lot of {( )} spam that can be hard to visually parse at times, esp. if you've been coding for hours or you're not completely awake. Plus, he probably didn't have a fancy text editor with syntax-highlighting, brace-matching, etc.

And if someone doesn't like it, it's not terribly hard to search & replace all his define's back to the original C syntax.

On the contrary, I find { } a lot easier to distinguish than begin-end crap in other languages, especially if I put the braces in their own lines. Also I hate uppercase variants of native C lowercase keywords, because all they do is slow my typing and my reading down.

[hex11]

Sure you can put { } on separate lines, but it still looks weird, and also it opens the path to all the different kinds of whitespace/brace styles in existence, which get hated as equally, because hey that other dude's style sucks only mine is good damnit. ;)

[Graf Zahl]

All that 'keywords are easier to read' nonsense really puzzles me. The meaning of braces is implicit: {'s counterpart is a }, just like a ('s counterpart is a ).

But hey, for someone who doesn't know any English whatsoever BEGIN and END are just random collections of letters, nothing more. All their meaning has to be explicitly stated - quite unlike something as neat as braces.

Concering formatting style, I have seen badly formatted PASCAL code, too, but unlike C it's a lot harder to comprehend because you don't just have to look out for symbols but for actual words. Even worse, there's several different types of words denoting different kinds of blocks.

Do you still wanna tell me it's easier?

[hex11]

There's no "objectively better" way, it's more like whatever the coder is most comfortable that is the correct method. And if he's constantly working against the language, then maybe it's time to find another one instead (if that's an option). But in this case he's just making use of the preprocessor, and the include file isn't even that big.

Btw, my favorite language is Perl, so braces aren't much of a problem for me. ;) But I also appreciate the freedom that this language gives me to code in any style or paradigm I wish.

[chungy]

I do a lot of work with Python recently and it's always amusing to notice when someone is so engrained with C-like languages that all the statements are terminated with ; (which is not required in python, but it is supported syntax, mainly for the rare cases that multiple statements per line has a good use). Then of course you get people that don't conform to indent style already in the files -- sometimes it's harmless things like not having an indent spacing in the multiples of 4, then there's people whose editors save actual tab (\x09) characters... which isn't QUITE such an issue anymore since mixing space and tab-based indents in the same file is an error in Python 3.x rather than just a warning.

Oh and where I work all the crap in Java has absolutely nobody saying you shouldn't go past 80 characters per line... or any limit at all. I still get wrapped lines when I maximize Emacs on my laptop (1280x800) even, and it's annoying as all hell.