Doom Legacy issues

I has seemed to me that "c:\Program Files" was for program installs that used an installer (and the registry) (OK, it is not in the Windows directory). This seems to promise a Windows like install, and I doubt I know enough to pull it off correctly.

I was leaning towards installing to "c:\games\doomlegacy" because it is similar to what other similar games did. It is less misleading.
To do better, what I need is a few hours of donated effort by someone with a Windows development background.

It is mistaken that I am the one and only contributor to DoomLegacy.
For me to buy a Windows development suite and become a windows developer, just for this, does not make sense. I think that Wine requires all that too. It does not emulate Windows, only hosts it.
The best I can do right now is maintenance, until someone with a Windows development suite can address the modern Windows issues.
It is not rational to be ripping out the whole Windows port just because the project lacks a Windows person at the moment.

...but it lacks the fundamentals to run on new versions of Windows, therefore that nulls the whole point of the port in the first place..

Went through an old pile of budget card driver CDs today. Ye olden nVidia FX card driver from 03' had drivers for 98 specifically. The Xtasy1300 from 11' (gpu from '05) had a 9x catch-all driver. My nVidia 8400 card from 13' (gpu from 08')only has an xp driver.

So to be clear, you are consigning windows users to a niche, i.e. those who happen to have old systems or those willing to buy older hardware.

Reactos (targeting windows server 2003)btw would mainly be for getting the installer tested and maybe seeing if the software renderer works minus sound. Wine would be for testing the graphic layer. True, it would be with linux drivers, but that will get the binaries tested at a minimal level.

chungy said:

If you make an installer, use "%ProgramFiles%\Doom Legacy" and none other.

I'd argue against that for Doom ports, because Program Files on Vista and up is protected by folder virtualization and that makes it a hassle for programs that use DOS-era paradigms like having the program and its data and user files (like saves) all in the same directory.

Like if you want to install your Doom portin Program Files, then you need to go the whole distance and use AppData for storing the config, My Documents/My Games for storing saves, and so on.

The default make_options is now filled out with almost everything that could be included in it. Extensive checking and automation now prevent many of the compiling mistakes. It errors instead of defaulting now.

I have been working on the Makefile, now including an installer and uninstaller.

It should not be this hard to install one executable, one docs directory, and a legacy.wad into DOS/Windows.

Install and Uninstall are one long grind because the DOS and WIN32 command interpreter lack so many functions. I am not requiring that the user install some package like GNU utilities. The point is to port to the available system, including only using whatever command it happens to have.
If I knew anything about how the Windows install works I might be tempted to make some use of it. I would still have to use only DOS commands for DOS anyway.

Today I fought with xcopy. When copying a source directory, it behaves strangely. It copies the directory contents instead of copying it as a directory, and sometimes adds some other directories too.

Still fighting with uninstalling the docs dir, which is three directory levels deep. I cannot find any way to delete the subdirectories in DOS commands. Doing 'del docs/*' will delete all the files, but leaves the directories behind.

There will be a list of about 10 directories that will be searched for legacy.wad and doom wads. Because this list is set by compile config, it is not changed for the different installs. Still looking at some variations, such as a couple of home directories, and a couple of subdirectories with the executable.

Am providing the following, so the user can choose:
They can also set the install directories in make_options.

make install_sys
.. installs to a system directory
WIN32 => \Program Files\doomlegacy
LINUX executable => /user/local/bin
docs, legacy.wad => /usr/local/share/games/doomlegacy

So from what Gez said, Vista users should not install_sys ??
It seems that the executable and legacy.wad could go there, as long as doomlegacy can find and run it from there.
Shouldn't share wad files go somewhere else in this situation?
DoomLegacy will still look in \games\doom and \games\doomwads and a bunch of other directories for legacy.wad and doom wads.
Saves and user config all go to the Home directory, same as in Linux system installs. There is no user data going to Program Files.
Even if the user cannot install in Program Files, I expect an administrator could install there (similar to Linux isn't it).

make install_games
.. installs to a game directory
WIN32 => \games\doomlegacy
LINUX executable => /user/local/games/doomlegacy
docs, legacy.wad => /usr/local/share/games/doomlegacy

make install_user
.. installs everything to a user directory, owned by the user
WIN32 => $(HOME)\games\doomlegacy
.. but have to test that the make can find HOME on Windows ...
LINUX => $(HOME)/games/doomlegacy

Found and am fixing a shutdown error loop in the SDL port that was triggered when legacy.wad was missing. This caused some chaos in that situation. Have rewritten the shutdown protection for all ports.

Are you expecting Windows users to use a native stand-alone port of "make" for Windows? Because, usually, in order to use "make" in Windows you'll have to be in a Cygwin or MSYS environment anyway which (a) have a Unix-like file system abstraction layer and (b) already have install, mkdir, cp and friends installed. But then, separate make rules for Windows don't make any sense at all.

And furthermore, there is the convention of using the DESTDIR variable. Why re-invent the wheel thrice?

Windows installers are typically just regular programs, that run as administrator and setup the proper %ProgramFiles% directory and registry entries for the Add/Remove control panel. An uninstaller is a program that does precisely the opposite. There is no package manager or like in Windows

Sigh...

You just don't get it, do you?

All you need to provide on Windows is a simple zip file where the executable, all required DLLs and data files are grouped together so that all the end user needs to do is to unpack it into a directory of their choice and run it - JUST LIKE NEARLY ALL OTHER DOOM PORTS DO!

(Of course that requires that the port actually works without throwing weird errors - which it did last time I tested it.)

I haven't met a Windows user who wasn't a total computer illiterate to not get that to work - and you can bet that total computer illiterates have no interest in Doom or even the required knowledge to set up the game properly to use the IWADs.

Actually I have this Makefile compiling, installing, and running on Win98, using MinGW and NOT having MSYS, at least for install_games and install_user.

I have NOT installed MSYS because I do not want to force the end-user to have it, just to run a few commands for install. It would be easier for me, but puts another requirement upon the user which leads to another reason for complaints. I would agree with them that it should NOT be necessary to have MSYS, just to install.

Thanks fabian, I was not aware that MS compile suites cannot handle makefiles. All I know of that situation is that the code has #if to detect Windows situations, and apparently someone at some time was compiling it on MS compilers. If there are any clues as to how they were doing that, I cannot recognize them. This will have to wait for someone with a Windows background to fix. The best I can do right now is to not wreak it too much for MS compilers.

This is the makefile in the source code package, not the binaries install package.

I know that building DoomLegacy in Windows is daunting. There will be few that will try it. To get someone to compile it under a modern Windows environment, it appears that I will have to do as much as I can to automate it for them. The unfortunate part is that my test platform is MinGW32 on a Win98. Maybe some Windows developer will finally submit some bug fixes.

I suspect that the MinGW make is taking the line:
>> del docs\*
and make transforms it ===> del docs*
which then deletes the whole directory content.
Using docs\*.* also does not work, as dir gives error messages.
Have tried several variations that have not worked at all.

Backslashes in Makefiles on MinGW, cannot tell if MinGW make is going to process it as a backslash or pass it through.
Going to have to $(subst ) them in at the last moment, see if that works.

>> del docs\\images\\*.*
does not work
1. del complains that there are too many arguments. It seems that issued from make it does not allow multiple files to be deleted.
2. When issued from a command line it queries the user, "Do you really want to delete the entire directory?".
3. the \\ goes through and appears as \\ , the MinGW make did not process it as a backslash.

I have seen other projects have an Windows installer they wrote in C code.
I never knew why they had to resort to that.

The only Doom source port I've seen that has an installer is Doomsday. In my opinion it's useless and annoyning, one of the devs promised a portable Win release at some point onwards.

Most programs use installers created with a tool like Innosetup, Installshield etc.

Since Doom Legacy will not be saving settings in the registry or saving setting in Appdata (for multi-user support) and does not need installation of a service or driver, or creating shortcuts or adding a firewall exception then you don't need to invest time in this.

Thanks VGA. That was my initial opinion. Did not want to go as far as to have to use something like InstallShield.

However, it seems that there is a DEMAND that there be an installer capable of being used by the computer illiterate. It has been said that DoomLegacy is not worth touching because it is too hard without a totally automated install.

wesleyjohnson said:

It has been said that DoomLegacy is not worth touching because it is too hard without a totally automated install.

Nonsense.

What has been said was that your distribution was a mess that people failed to handle correctly because it was so broken.

Do you have ever seen any complaint about (G)ZDoom, Eternity or PrBoom+ to be hard to set up? I haven't and they all come in a Zip with a portable installation.

You are making a mountain out of a molehill here but you completely fail to address the one glaring issue with the way you have constructed your Windows Zip (i.e. not putting the required DLLs in the main directory but forcing the user to copy that stuff around - and that's ALL that was being complained about!)

Doomsday may need an installer because it got way too complicated over time - but that's an entirely different story.

InstallShield is not free.

Microsoft installer.
The instructions for Microsoft installer go on for more than 30 downloads. They broke the instructions up into a maze of little pages.
I get the feeling that after wading through all that, I am going to find out that the only tool that can write the install file is going to be a MS SDK.

Forget the goddamn installer! We don't need that.

But if you still insist, check out Inno Setup, that's the tool my employer uses for everything they have to distribute as a Windows installer, and it's free.

But please do us all a favor and skip that nonsense. I don't even know if there's still install tools out there which can target every Windows version, nobody cares about Win98 anymore.

wesleyjohnson said:

InstallShield is not free.

Microsoft installer.
The instructions for Microsoft installer go on for more than 30 downloads. They broke the instructions up into a maze of little pages.
I get the feeling that after wading through all that, I am going to find out that the only tool that can write the install file is going to be a MS SDK.

Graf just gave you a simple, effective, easy, free method. Here are the steps:

1. Manually set up Doom Legacy on your system, with all of the required files in the same folder, and all config files pre-configured to defaults known to have the best chance of success "out-of-the-box". (Default keybindings, normal resolution (640x480 maybe, or even 800x600)). Possibly you could use this opportunity to showcase some of your ports features (translucency on, etc.). But, the point is that it should work for the user without modification. Don't worry, the user will find all the settings eventually.

2. Make sure the program does in fact run properly in that folder.

3. Delete any temporary files, save games, etc, created by Step 2.

4. Use WinZip to compress the entire contents of that one folder into a Zip file. Name the file <myGameName>Setup-v1.1-Win32.zip, or something similar, with game name, and version number.

5. Distribute, and rejoice. The install has been built. With your Zip file, I should be able to UnZip into a new folder that I have named "Doom Legacy", place my IWAD in that folder, and double-click Legacy.exe, and see the title screen. The README file (which should be findable in that same folder) will become useful to me AFTER I've decided that your port interests me... which is AFTER I've run it, not before.

You don't need any InstallShield, Microsoft installer, or anything other than a program that builds Zip files (or 7Zips if you want to get fancy. Personally, I'd stick to the universal standard: WinZip). I think the registered version will build an .exe out of the Zip, so your users can "install" your app by starting the .exe. I prefer a Zip file, however - it feels safer to me.

If you do plan to offer a Windows installer I would recommend taking a look at WiX Toolset. In my experience it is far more flexible than Inno Setup.

What kind of flexibility do you need to copy a handful of files to a single folder?

This is ridiculous, a zip is fully sufficient for something this simple.

For crying out loud Graf - let it drop. We all get that you don't like installers, despite that there are perfectly valid reasons to use them on Windows.

Yeah, a ZIP may well be sufficient for Legacy. My comment was not about Legacy specifically (review my phrasing) - it was general advice based on experience with such things.

Best of Both Worlds: the standalone Zip approach and an installer.

Stop all the makefile-based install instructions nonsense. It's completely unreasonable to even expect make to be installed on an average Linux user's computer, much less a Windows user's. Makefiles are for development purposes, not an installer.

Just do what Graf asks at a bare minimum. That's what the Doom community expects.

chungy said:

Stop all the makefile-based install instructions nonsense. It's completely unreasonable to even expect make to be installed on an average Linux user's computer, much less a Windows user's. Makefiles are for development purposes, not an installer.

So people who like to compile things by hand and then install them, however a niche market they are, should be thrown under the bus? As far as I am aware, "make install" is a standard feature. I don't see the logic behind your suggestion of removing it, chungy.

I'm sorry, I wasn't as clear as I should have been. Yes "make install" should remain for the adventurous and for distro packagers and so on. It has uses, but not for the average end-user.

The average end-user simply wants a Zip file to unpack, or an installer, or a package to install. They won't want to be using make to do it.

The Makefile is in the source code distribution. Any discussion about the Makefile is NOT about the binary distribution.

I do not make up the binary distributions. That is another team member. I send to him the individual binaries that I can build.

There appear to be three desirable install locations.
1. User:
The person who does not have Manager permissions usually installs for use only by themselves.
2. Games:
Traditional Games install location for Linux, FreeBSD, Mac, and the like.
With windows, this keeps it out of the Program Files. Would not actually need an installer, but an installer is more sure than try to get users to read the instructions. User can delete the games directory to uninstall.
3. System:
Some games, like flightgear, will install to /usr/local/bin
with most data files in /usr/local/share/.
On windows this would be the Program Files. Requires administrator rights. This would seem to also want menu entries and shortcuts, which are going to be somewhat difficult for me to setup.
Would not expect any user or administrator to delete a directory in Program Files without trying to run an Un-install first.


Considering the Binaries packages:
I am not fond of installers either.
It is hard to deal with the requirements for a Windows install, and an installer would be able to deal with it better than I can.
The alternative would seem to require a separate zip download for each.
I would rather use a batch file, than an installer, but do they even work for modern Windows. I cannot test them.
A separate batch file for each install target would probably be simple enough.
I have no idea what batch file commands would be used to create menu entries or shortcuts.
I suppose for some, that selecting and running a batch file installer would be too much to expect.

Have rewritten (again) the program code of searching directories for
legacy.wad and the iwad. More directories, handles a home directory case better now, and finds legacy.wad even when DoomLegacy is run from a different current directory. This fixes some cases that I had thought worked but failed during testing of the installer. Having an installer in the Makefile is giving this code area more testing now.

Sigh...

Why, oh why?

Why don't you JUST do what everybody tells you to do, i.e. just zip up a directory that contains everything that's required for starting the whole thing and be done with it? You don't even NEED Windows for that, aside from ensuring once that everything required is present.

EVERY other Doom port (except Doomsday, of course) has no issues whatsoever with a similar setup.

It's so simple, yet you seem to overinflate this straightforward procedure into a huge problem. I don't get it.

Graf Zahl said:

It's so simple, yet you seem to overinflate this straightforward procedure into a huge problem. I don't get it.

Yeah dude, just do what the rest of us do - put it in a zip file, provide the DLLs in the base directory, and be done with it. IMO installers for a source port is overdoing it. Further, why go through the work if Legacy still doesn't run on new versions of Windows? Getting it working properly should be number one...

The current zip files can be used in exactly that manner. But the complaints here indicate that you are unwilling to read the instructions and install them properly.

From the complaints here, it seems that the problems are as much install problems as anything else. In these complaints I cannot distinguish install problems from any code problems because YOU cannot distinguish them.

It seems the best thing I could do is make sure it is installed in some consistent way, and be able to identify exactly which way it was installed.

Zipping the files as they appear on my machine would do you no good at all. My install is for development and is much different than what you would use. How and where you install doom packages I cannot guess, and in all these replies no one has said or even offered a preference. I especially have to guess at what Windows users are doing, because I do not download or install any doom ports to Windows, so I am unfamiliar with "what everyone else is doing" on Windows. Looking at the source code packages has not given me any insights either.

An inflexible install that only works for some users does not appeal to me. I believe in allowing the user the flexibility of installing for themselves, or in ways that I cannot predict. This currently was done by extensive instructions.

So, no one is demanding that short cuts and menu entries be made on Windows as part of the install. I thought that was a standard of the Windows experience and a necessity because of the lack of a command line.

A special thanks to Alexy Dokuchaev who actually sends in bug reports with suggested code fixes. He reports that the latest changes work to allow compiling with clang, generating dep files now works with clang, and also that it now compiles on the PowerPC.

wesleyjohnson said:

The current zip files can be used in exactly that manner. But the complaints here indicate that you are unwilling to read the instructions and install them properly.

For god's sake, what's up with you?

No, the current Zip files can NOT be used 'in exactly that manner'!
I have told you `many, many months ago that putting all the DLLs in a subdirectory is not only unnecessary but it creates a barrier the user first has to pass before he can use it.

Having to read instructions to 'install' something that should never need installing is just idiotic. Put the DLLs in the same directory as the EXE and all should be fine. I really don't get what's such a big problem here?

It was explained before and in the instructions that SDL is required to be properly installed by the user. You do not get to dictate this, so stop acting like an ass and a bully trying to verbally beat me into some kind of submission on this point. You have been told before that those SDL in the side directory are there to be used only if the user does not have a better and newer SDL installed, and you were told the reason why.
I do not respond to threats (no one will use your port unless you do as I say) and abuse (almost everything else you post), and specifically not on this matter.

In Windows the users don't install SDL. The dll files are just in the same folder as the program binary.

So the user unzips the release in a folder and runs it.

VGA said:

In Windows the users don't install SDL. The dll files are just in the same folder as the program binary.

So the user unzips the release in a folder and runs it.

Precisely that. Which I also said multiple times in the past which got persistently ignored.

Installing SDL wouldn't work anyway, because the differences between versions can easily break an application using these DLLs.

wesleyjohnson said:

I do not respond to threats (no one will use your port unless you do as I say) and abuse (almost everything else you post), and specifically not on this matter.

Why should I threaten you? I merely state facts. Nobody WILL use your port if it presents itself like a mess to the end user (hard to get running, unclear error messages, confusing visual presentation and most of all, not properly working.)

wesleyjohnson said:

You have been told before that those SDL in the side directory are there to be used only if the user does not have a better and newer SDL installed, and you were told the reason why.

Which is every single Windows user that will ever attempt to use your port, ever.

I have practically every maintained source port on my Windows PC, and I guarantee Legacy will not run if I just unzip it, drop my iwad in and run the executable, despite the many SDL powered engines I have.

And it won't be because I don't have SDL properly installed, it's because your engine is broken when freshly unzipped and you refuse to listen to the advice of multiple developers that actively maintain source ports for multiple operating systems to this day, including Windows.

I don't know what else to tell you other than you have no idea what you're talking about when you think SDL should be installed on a Windows PC. This isn't DirectX and this isn't Linux.