Porting codebases to 64 bit

[Baker]

Archlinux' AUR rocks and makes maintaining/installing packages trivial

Which is another way of saying no application can ever achieve a status of "completed", regardless of how simple it is.

This is my main objection to using Linux (and probably ultimately the only objection).

You can never complete an application for Linux, you can only start one.

Fails the "the machine is subservient to the man" paradigm test if the operating system places requirements on to the human. The more applications you write for Linux, the higher and higher your overhead will become and at some point you will only have time for overhead. The only way to avoid this overhead is not writing for Linux.

[I'm not flaming Linux, I'm identifying why the lack of stability has major detrimental side effects. Ironically a Win32 application requires less maintenance running on Linux than a native Linux one.]

One of the things, none of the distributions have ever done right is application packaging [...] making binaries for linux desktop applications is a major fucking pain in the ass.

I might as well take the opportunity to point what Linux does well:
1) System binaries know where they go.
2) Development stuff knows where it should live

And some of the stupid emerging things on Windows:
1) c:\ProgramData WTF! It isn't like Windows doesn't already have %AppData% folder that --- well -- that has tons of places it might be. And it isn't like Windows doesn't have have a "My Documents" kind of folder.
2) Program Files and the x86 version. You mean the system can't tell the difference? And the SysWow64 vs System32 folder.
3) And the funny fake directory that something in Program Files writes to if it tries to write to its own folder, creating 2 places.

(But at least the dumb quirks on Windows are transparent to an application.)

[mh]

Program Files vs Program Files (x86), together with System32 vs SysWow64 both feel like something that Raymond Chen may have written about in the past. My money's on there being an application compatibility reason for both, because Windows users don't have the luxury of throwing everything out and starting again from scratch. A new x64 system must be able to continue to run old x86 programs, even if those programs were written in a time before x64 even existed. Of course Microsoft don't always get it right (and they frequently enough get it wrong for stupid reasons), but this is the kind of thing that doesn't just happen for no reason at all.

Spirit's comment about YAPM (...figure it out...) made me chuckle. Far too often the Linux preferred solution is to write yet another competing product rather than just fixing what's already there. How many package managers are there anyway? And this time next year people will be extoling the virtues of yet another one (that's almost but not quite totally incomaptible with those that already exist); guaranteed.

[Baker]

Program Files vs Program Files (x86), together with System32 vs SysWow64 both feel like something that Raymond Chen may have written about in the past. My money's on there being an application compatibility reason for both, because Windows users don't have the luxury of throwing everything out and starting again from scratch.

I can accept those, despite not being fond of them (I image the c:\windows\system folder was for 16-bit stuff). But c:\programdata or whatever is bit much to handle.

[mh]

I can accept those, despite not being fond of them (I image the c:\windows\system folder was for 16-bit stuff). But c:\programdata or whatever is bit much to handle.

Much of C:\ProgramData is just junction points to the All Users profile. I guess that Microsoft just wanted to make a distinction between application files (i.e executables, DLLs, etc) used by programs and data files used by them but which are not specific to individual users, which this seems to bear out: https://social.technet.microsoft.com/Fo ... ata-folder

[JasonX]

For people from the future browsing this thread: I eventually gave up. I've used some static analysis tools to help me track the errors related to 64-bit, but the constant crashes were a major turnoff. So, no base 64-bit WinQuake.

[frag.machine]

Oh well, thanks for the feedback. Platform migration is hard stuff.