Forum

Porting codebases to 64 bit

Discuss programming topics for the various GPL'd game engine sources.

Moderator: InsideQC Admins

Re: Porting codebases to 64 bit

Postby Baker » Sun Mar 01, 2015 7:22 pm

Spirit wrote: 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.]

Linus Torvalds - Aug 2014 wrote: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.)
The night is young. How else can I annoy the world before sunsrise? 8) Inquisitive minds want to know ! And if they don't -- well like that ever has stopped me before ..
User avatar
Baker
 
Posts: 3660
Joined: Tue Mar 14, 2006 5:15 am

Re: Porting codebases to 64 bit

Postby mh » Sun Mar 01, 2015 11:39 pm

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.
We had the power, we had the space, we had a sense of time and place
We knew the words, we knew the score, we knew what we were fighting for
User avatar
mh
 
Posts: 2286
Joined: Sat Jan 12, 2008 1:38 am

Re: Porting codebases to 64 bit

Postby Baker » Mon Mar 02, 2015 1:17 am

mh wrote: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.
The night is young. How else can I annoy the world before sunsrise? 8) Inquisitive minds want to know ! And if they don't -- well like that ever has stopped me before ..
User avatar
Baker
 
Posts: 3660
Joined: Tue Mar 14, 2006 5:15 am

Re: Porting codebases to 64 bit

Postby mh » Mon Mar 02, 2015 11:37 am

Baker wrote: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
We had the power, we had the space, we had a sense of time and place
We knew the words, we knew the score, we knew what we were fighting for
User avatar
mh
 
Posts: 2286
Joined: Sat Jan 12, 2008 1:38 am

Re: Porting codebases to 64 bit

Postby JasonX » Mon Apr 17, 2017 7:39 pm

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. :confused:
JasonX
 
Posts: 407
Joined: Tue Apr 21, 2009 2:08 pm

Re: Porting codebases to 64 bit

Postby frag.machine » Tue Apr 18, 2017 5:03 pm

Oh well, thanks for the feedback. Platform migration is hard stuff.
I know FrikaC made a cgi-bin version of the quakec interpreter once and wrote part of his website in QuakeC :) (LordHavoc)
User avatar
frag.machine
 
Posts: 2052
Joined: Sat Nov 25, 2006 1:49 pm

Previous

Return to Engine Programming

Who is online

Users browsing this forum: No registered users and 1 guest