Doom Legacy issues

We are walking in circles:

1) everybody tells wesleyjohnson that it should not be necessary to read the docs to get the port running and that he should simply drop all the necessary files into a ZIP

2) wesleyjohnson replies that there are specific reasons not to do this and that everybody should read the docs

3) repeat step 1

Deja-vu anyone?

fabian said:

We are walking in circles:

1) everybody tells wesleyjohnson that it should not be necessary to read the docs to get the port running and that he should simply drop all the necessary files into a ZIP

2) wesleyjohnson replies that there are specific reasons not to do this and that everybody should read the docs

3) repeat step 1

Deja-vu anyone?

Not quite but close.

I'd say it is as follows:

1. SDL libs are in a subdirectory because wesleyjohnson is stuck in the false belief that these need 'installing'.

2. everybody tells wesleyjohnson that there's no need and no reason to do that - just put them in the same directory as the executable and be done with it.

3. wesleyjohnson replies that this is done so that any 'installed' version of them can be used instead.

4. repeat step 1.


Seriously, this is getting ridiculous. The issue first came up 11(!!!) months ago and for all those 11 months the uniform reply of ALL Windows users has been to forget about the 'installing' issue and just put those DLLs alongside the executable - and yet we are stuck at the same precise point - like a broken record. How do you deal with someone who's completely and utterly resistant to any advice on the matter?

I wonder if wesleyjohnson's problem is he has the mistaken impression that you're meant to "install" SDL's DLL libraries in the Windows directory, akin to how various system critical libraries or most Linux libraries are typically installed, rather than as side extensions grouped with the executable (which is how SDL is supposed to work, given its multiple versions and variants).

Although this line of thinking doesn't make much sense, because even Windows 95 worked like this, and thus can't be because he's been away from a proper version of Windows for vastly too long. But it's the only line of thinking I can deduct from his logic.

That seems to be the case. Still, why doesn't he listen to anything what has been said over time - which was quite clearly and outspokely telling him that this is not the way to do it - by several people! - and yet yesterday the same bogus reasoning came up AGAIN!

I'd really not like to see a reply from wesley there until he's done his homework and actually understands what DLL hell is.

Yeah, SDL isn't something to be installed, it's a linked library that gets included with your port, located in the root directory of your executable.

And wait, someone mentioned (Graf?) that the Legacy team as a whole agreed not to support later versions of Windows because of the WGA?
...
Did they all pirate Windows XP/etc or something? That's the stupidest reason I've ever heard not to use an operating system.

Also, for a port like Doomsday, I can see where an installer would be important, because it's high-end and customizable. Legacy is the exact opposite (still DOS compatible? DAMN), so it doesn't need anything fancy. I could just imagine getting ahold of Installshield for 3DGE...now say that over a few times in your head...doesn't it sound stupid? =)

Chu said:

And wait, someone mentioned (Graf?) that the Legacy team as a whole agreed not to support later versions of Windows because of the WGA?
...

This was a long time ago, so please excuse that my memory is a bit spotty.

But as far as I remember, development back then already was done on Linux. And in 2001 or 2002 there was some announcement about that matter. I haven't followed how things progressed because the port already was extremely unstable, and causing a shitload of problems on my XP system - and with no improvement to be expected I just did what everybody else did: I dumped it, never to be used again.

Yeah, Doom Legacy is best on Win9x, where it belongs. Just drop support for NT and let it die. As soon as the controls for splitscreen are completed for 3DGE (hint: any day now), I'm sure it'll replace Legacy's only, well, legacy - splitscreen multiplayer.

wesley, have you considered migrating over to Legacy 2.0? Was there a reason why that stopped?

wesleyjohnson said:

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.

You know, I have, on multiple occasions, defended you, in multiple threads, when I felt that you were being unfairly treated. But, I have no defense for your stance on this install "issue".

By advertising and offering your port, compiled and in source form, release notes, and readme files, there is an assumption that you care to have people use your port.

Now, I know that I have not threatened or attacked you. And, I know that, yes, your port will not be used if it cannot be intuitively installed without having to read directions. I've installed a lot of ports, and I do not read the instructions, unless something goes way wrong. That's what Graf was saying. ("threatening" you? Seriously? A little drama with your coffee, eh?)

I imagine that Graf would probably tell you himself that he is blunt with his observations, and, at this point, I imagine he is (as I am) frustrated with your responses.

Here's what I don't understand: Why won't you spend all of 5 minutes, to:
1. Create a folder on your HDD.
2. Place ALL files required by Legacy, including an IWAD, into that folder.
3. Run that copy of Legacy, and prove to yourself that it runs ok.
4. Remove the IWAD from that folder.
5. Zip the folder's files into a single Zip, and release it to the world.

It took you much longer to type up your responses than it would have take to build the Zip file, 10 times over. Anyone reading this thread will realize that those steps above will make the majority of your user base happy. And, it only takes 5 minutes of your time.

The users come first. If you've lost sight of that, I honestly have no idea of what your intentions and motivations are, as they appear to be incongruent with your actions.

Chu said:

Yeah, SDL isn't something to be installed, it's a linked library that gets included with your port, located in the root directory of your executable.

Part of the issue is that since, on Linux, SDL is expected to be installed, Wesley is pretending that Windows should act exactly the same as Linux. It doesn't :P

I installed SDL on the Win98, system wide, for all users.

Do you expect that a single SDL binary is going to be the best SDL for Win98, Win7, Win8, Win10, and future Windows versions ?

SDL must be closely adapted to the OS it is running on. On Windows it has problems like the volume control. The SDL problems with Windows are so extensive that I would rather the user pick the SDL version that they find works with their OS. That requires that they install it themselves.

If a supplied SDL were to be in the executable directory, it would get used even if the user had installed a better SDL. I have no way to test a different SDL than I am using, and could not test them for most of the Windows versions that have the most problems.

The claim is that this a not a drop-in shake the box package, and that is intolerable. I do not have such a narrow view.
I cannot blindly obey your demands, when I have little reason to believe that I could build such a drop-in package correctly, and do not have the facilities to test such a thing.
From my view, not being able to tolerate a package style that is not a drop-in with integrated SDL dlls is really a tolerance problem.

If they're having problems with the sdl dlls you're providing with legacy then they can just delete the dlls or move them out of the directory.

wesleyjohnson said:

I installed SDL on the Win98, system wide, for all users.

Do you expect that a single SDL binary is going to be the best SDL for Win98, Win7, Win8, Win10, and future Windows versions ?

SDL must be closely adapted to the OS it is running on. On Windows it has problems like the volume control. The SDL problems with Windows are so extensive that I would rather the user pick the SDL version that they find works with their OS. That requires that they install it themselves.

If a supplied SDL were to be in the executable directory, it would get used even if the user had installed a better SDL. I have no way to test a different SDL than I am using, and could not test them for most of the Windows versions that have the most problems.

The claim is that this a not a drop-in shake the box package, and that is intolerable. I do not have such a narrow view.
I cannot blindly obey your demands, when I have little reason to believe that I could build such a drop-in package correctly, and do not have the facilities to test such a thing.
From my view, not being able to tolerate a package style that is not a drop-in with integrated SDL dlls is really a tolerance problem.

All I know is that other SDL ports don't seem to have such difficulties with their zip-file installs, so, clearly, it's working for them. Because of that, it's something worth considering. Either way, good luck.

Programs should only be used with the version of SDL they were linked against. The idea that the user should use a "better" version of SDL than the one you built and tested the program against is completely wrong.

Besides the fact that there may be API or ABI changes which cause it to not load or to crash at runtime, it's a completely moot point if you are still using SDL 1.2, as that library has been deprecated and will not be updated any further. SDL 1.2.15 is the last version, period. If you want further progress, you must migrate to SDL 2.0 at this point.

wesleyjohnson said:

I installed SDL on the Win98, system wide, for all users.

This highlight so many problems right here. By "system wide" I'm assuming you're talking about %SystemRoot%\system32 or %SystemRoot%\system as is the case on Windows 98 (which by default is usually C:\Windows\system). You are never, never, never supposed to add, delete, or modify files under the Windows directly, so please stop this ridiculous and dangerous assumption. In fact, Windows Vista and newer with UAC enabled actively prevent any process from doing so (with few exceptions made for Windows Update and others). Then there's the fact that Windows 98 doesn't even have users, not in any real sense anyhow.

Windows is meant for completely self-contained programs, whether that's statically linked executables or all of their dynamically linked libraries stored within the application directory. Asking users to do anything else is insane, and asking them to modify their Windows directories is downright malicious. Asking users to manually copy around SDL DLLs just so your port can work is a major deterrent to running it at all. After all, pretty much every other SDL-based port on Windows works out of the box as-is.

(The only major exception to this rule is Cygwin, which emulates a Linux environment anyway, and still has the sensibility to not fuck with the operating system directories.)

Ok, let's go through it. I know I'm mostly repeating what has been said in previous posts but I think it's necessary.

wesleyjohnson said:

I installed SDL on the Win98, system wide, for all users.

Now we are getting to the root of the problem. Finally.
What did you do? Copy SDL to the system32 directory? If you did that, congratulations for violating any sane approach to install software on Windows.
This also won't work on more modern versions as has been said. The system directories are protected now so you can't just copy your own stuff there. To get a library installed as a shared resource there's quite a bit more to be done, but that'd exceed the capabilities of any but the most knowledgeable users. And those knowledgeable users know better than to do such dangerous stunts.

No sane Windows user whould do such a thing. In the end you are doing no one a favor as none of your Windows users has SDL installed so all of your Windows users will have to do some manual intervention to get Legacy running.

wesleyjohnson said:
Do you expect that a single SDL binary is going to be the best SDL for Win98, Win7, Win8, Win10, and future Windows versions ?
[/B]

There is no 'best SDL'. As Quasar said, the only proper version is the one you linked against - nothing newer, nothing older. Don't assume people have the right one sitting somewhere.

In any case, (I repeat myself here) nobody got SDL 'installed' anyway. All applications on my system which use it ship the SDL.DLL or SDL2.DLL along with them. And all run out of the box. Only Legacy doesn't.

wesleyjohnson said:

SDL must be closely adapted to the OS it is running on. On Windows it has problems like the volume control. The SDL problems with Windows are so extensive that I would rather the user pick the SDL version that they find works with their OS. That requires that they install it themselves.

No. Completely wrong on all accounts. And completely overestimating your end user.
First, there is no 'SDL install' package available, and second, as said above, compatibility is not guaranteed between versions. This is never going to work. You are trying to transport Linux conventions to a system that has completely different conventions.

wesleyjohnson said:

If a supplied SDL were to be in the executable directory, it would get used even if the user had installed a better SDL. I have no way to test a different SDL than I am using, and could not test them for most of the Windows versions that have the most problems.

Indeed. And THAT'S THE POINT! Stop thinking about this 'better' nonsense once and forever. It doesn't apply here. Oh, and didn't I tell you: SDL does not get 'installed' on Windows so the whole point is moot anyway.

wesleyjohnson said:

The claim is that this a not a drop-in shake the box package, and that is intolerable. I do not have such a narrow view.

Sorry, but may I laugh. I'd say your view is even narrower because you seem to stuck in this false belief despite everybody else telling you that this is wrong.

wesleyjohnson said:

I cannot blindly obey your demands, when I have little reason to believe that I could build such a drop-in package correctly, and do not have the facilities to test such a thing.

OMG! Are you serious? What makes you think that you alone are correct while everybody else in this and previous threads is telling you that you are wrong? Especially since you freely admit that Windows is not your platform of choice. In other words: You are not informed but you persistently ignore any advice from people who do know. As a result you distribute broken packages.

wesleyjohnson said:

From my view, not being able to tolerate a package style that is not a drop-in with integrated SDL dlls is really a tolerance problem.

THERE ARE NO INTEGRATED SDL DLLS!!! How often do we have to tell you that??? Your entire reasoning is based on a faulty assumption so any conclusions you draw from that are just as faulty, if not even more.
And we have been telling you this for almost a year and yet the same harebrained nonsense still comes up.

And last, but not least, you are still using Windows 98 which predates nearly all modern conventions, so anything you might consider proper on that dinosaur is meaningless today as many of these things have been blocked for security reasons.

In the bad old days of Windows 9x it was indeed quite common to 'install' shared libraries in the system directory, but this caused so many problems with incompatibilities that it eventually stopped because most people correctly assume that if they can guarantee that the library version they tested against get used, the risk of malfunction is considerably lower.

So why don't you just listen to people who actually USE Windows? Wouldn't you think they know better how to properly do stuff?

What I don't understand is how Linux gets away with this perfect setup for dependency hell. By all accounts it should suffer from some of the same problem that plagued Windows when this kind of library sharing was more common.

No, in the end the convention to have an installation be self-contained without any unnecessary dependencies elsewhere in the system is one of the cornerstones of Windows's compatibility track record.

Graf Zahl said:

What I don't understand is how Linux gets away with this perfect setup for dependency hell. By all accounts it should suffer from some of the same problem that plagued Windows when this kind of library sharing was more common.

Not sure either because I've heard of a few distros getting hosed by upgrading the wrong packages. You break something that you need that has a dependency on version "last" of something that updated which was an indirect dependency of the package and does not work with version "new". System is now hosed, and there's no form of "rollback" like a Windows restore point. If you didn't have a backup already, time to put in a Live CD, make one, and then reinstall the system.

Quasar said:

Not sure either because I've heard of a few distros getting hosed by upgrading the wrong packages. You break something that you need that has a dependency on version "last" of something that updated which was an indirect dependency of the package and does not work with version "new". System is now hosed, and there's no form of "rollback" like a Windows restore point. If you didn't have a backup already, time to put in a Live CD, make one, and then reinstall the system.

This happened on an LTS release of Ubuntu, where a linux kernel module didn't compile yet the bot responsible for checking packages somehow passed over those broken modules. The result was that the packaging bot packaged empty files as modules. Guess what happened when users upgraded?

Fortunately the FOSS community plays fair when adding features and if volunteers are willing to backport features, it will help when installing new software -- to a point.

Google packages everything in the box for their software. they take zero chances. Because of that, their software works, at the expense of a huge download size and disk space. Chrome installs can get up into the 300 MB range, easily.

I've also seen packages that depend on packages that depend on the package that I'm trying to install - but a previous version, or an older package with a different name that isn't aliased. oops! I can't install a damn thing.

Quasar said:

Not sure either because I've heard of a few distros getting hosed by upgrading the wrong packages. You break something that you need that has a dependency on version "last" of something that updated which was an indirect dependency of the package and does not work with version "new". System is now hosed, and there's no form of "rollback" like a Windows restore point. If you didn't have a backup already, time to put in a Live CD, make one, and then reinstall the system.

The broken state you refer to is rare on non-rolling release distros. I say rare since Csonicgo apparently knows of an incident with Ubuntu that I didn't personally run into. (Unless it was pre-2008 I'm kind of surprised I didn't.)

Similarly Ubuntu now packages old versions of some libraries (some notable examples being libstdc++, libssl, and libjpeg) for application compatibility. For most applications it's not necessary to have the exact version of the library it was compiled with, only that the versions are ABI compatible. Thus the naming scheme for system libraries on Linux actually includes an ABI version number. For example, the Doomseeker packages I provide are compiled against Qt 4.6 so they run on Ubuntu 10.04. The user can have Qt 4.8 installed and it works just fine since the libraries are ABI compatible and are both named libQt*.so.4. On the other hand, Qt5 breaks ABI with Qt4, so it is allowed to be installed concurrently and uses libQt*.so.5. (Kind of a bad example since Qt5 also puts the 5 in the file name, but the general pattern is used e.g. libjpeg.so.62 vs libjpeg.so.8)

The DLL hell problem in Windows 98 was due to the lack of any versioning support, assumed ownership (uninstallers), and probably way too many applications relying on undefined behavior. I run some old Linux games and usually the problems getting them to run have to do with OpenGL (some problems occur on Windows) or getting sound working.

The other thing is that Linux apps are constantly updated to adapt to changes in their dependencies. If the original team doesn't do it, distro package maintainers usually do, and if that keeps up, it gets forked. A lot of Windows apps are > 4 year old binaries or whatever, and of course that eventually causes problems. Hooray for open source.

That said, I think dynamic linking has been a big fuck up. Static linking is better in basically every way. Come at me bro ;)

Ladna said:

That said, I think dynamic linking has been a big fuck up. Static linking is better in basically every way. Come at me bro ;)

Ladna said:

A lot of Windows apps are > 4 year old binaries or whatever, and of course that eventually causes problems. Hooray for open source.

You know, approx. half of the apps on my system are older than 4 years - some are even older than 10 years. This rarely causes problems on Windows.

The two most notable changes that broke old apps was abandoning 320x200x256 colors by graphics driver vendors which rendered many old DirectDraw games unusable and the sound mixer change in Vista which affected MIDI playing software.

Aside from that stuff rarely breaks - let's just ignore the oddball application that was written by some idiot who did their best to work against the system.

To name an example, the original Quake2.exe from 1997 still runs fine on my current Windows 8.1 system, if you ignore that back then nobody thought about supporting widescreen monitors.

Ladna said:That said, I think dynamic linking has been a big fuck up. Static linking is better in basically every way. Come at me bro ;) [/B]

Dynamic linking is not the problem as it can make it a lot easier to integrate third party code.
The problem is when DLLs or their equivalents get shared by default. As long as they remain private to the application which needs them, no problem here

Well, Windows' commitment to backwards compatiblity is legendary. Plus there's the tendency to roll everything yourself (networking, compression, etc.), so deps are kept to a minimum. Plus those apps are all likely statically linked to lots of stuff, you just don't know it.

Keeping DLLs private to the app is basically static linking, except it's still slow, still easy to hook, and is still cluttered. It avoids DLL hell, but so does static linking.

Graf Zahl said:

To name an example, the original Quake2.exe from 1997 still runs fine on my current Windows 8.1 system, if you ignore that back then nobody thought about supporting widescreen monitors.

Your point is what exactly? The Linux kernel doesn't break user space compatibility. (Pardon the slightly old Ubuntu release, I'm at my grand parent's at the moment and he's stuck with a Geforce 6800 so I can't upgrade the OS. I can assure you it runs on Ubuntu 14.10 just as well.)

Windows's backwards compatibility isn't really any better or worse than Linux's, so yeah it's kind of an odd point. Maybe Linux's is even better; not just old Linux programs, but via DOSEMU (this is more akin to NTVDM; not a CPU emulator like DOSBox) you can still run DOS programs, and via Wine, you can still run 16-bit Windows programs.

Anyhow, Linux doesn't normally suffer from the same kind of "DLL Hell" mainly because it has been standard in Unix to name libraries by ABI version number. Most distributions (those that aren't rolling-release) will never remove libraries with the old ABI just for an update; and even those that are rolling release tend to provide extra packages for compatibility with the old anyway.

There's actually a couple things at play: Linux, the kernel itself, never never never breaks the user space ABI. Linux 4.0 compiled for amd64 should be fully capable of driving the complete user land for some 386 distribution from 1992. Then, there's the user space libraries itself, such as libc, X11, GTK, and so on. Most of those maintain good compatibility, although sometimes major releases will break it (and necessitates having, for example, gtk2 and gtk3 installed at the same time).

Anyhow, this is all fairly off-topic and I think wesley has abandoned the thread :D

Blzut3 said:

I'm at my grand parent's at the moment and he's stuck with a Geforce 6800 so I can't upgrade the OS.

Nouveau should be capable of running that card fine :P I believe Ubuntu will use Nouveau by default if you don't have NVIDIA's proprietary driver installed.

chungy said:

Nouveau should be capable of running that card fine :P I believe Ubuntu will use Nouveau by default if you don't have NVIDIA's proprietary driver installed.

All experiences I've had with Nouveau haven't been positive (crashes frequently, which is to be expected since it's all reverse engineered). Being able to run X-Plane 9/10 is a requirement so unless it has obtained 100% of the performance of the 173 driver, Nouveau is a no go. 12.04 will get updates until 2017 so I'm not really concerned about it right now. He's pretty much due for a computer upgrade anyhow. :P

okay but thread derailed any news about Doom Legacy a. getting revamped or B. ending the windows port? I noticed the newest build of Legacy does not come with Windows binaries, so that's a step in the right direction for now.

Probably a wise decision.

Just reading through the Make_WIN32.txt file makes my head hurt and it certainly explains all of wesleyjohnson's misconceptions and errors with providing Windows support.

Yes, there this really is mentioned:

Install DLL files in Windows\System32
  Copy or move
    SDL\lib\SDL.dll   to  \Windows\System32
   SDL\lib\ SDL_mixer.dll   to \Windows\System32

In short: No, NO, NOOO!!!

I'll try to compile this mess later today with Visual studio. My hopes are low but since a working Windows version doesn't seem to be forthcoming my only solution to analyze the setcorona code would be to run it through a debugger myself - I just hope it doesn't nuke my PC...

Just tested it and encountered these issues:
* Can't take a good screenshot, Nor can i record with software renderer.
* Netcode is Super slow,looks like it's cutting in middle of each action i do.
* Chasecam and Water physics are super cool (Wow is that a bug ?)

Graf Zahl said:

I'll try to compile this mess later today with Visual studio. My hopes are low but since a working Windows version doesn't seem to be forthcoming my only solution to analyze the setcorona code would be to run it through a debugger myself - I just hope it doesn't nuke my PC...

Well, no chance here, it takes great skill to write plain C code that only works with one compiler. The team that produced this certainly managed.

Under Visual C this throws an endless list of errors.