It is 64-bit



  • Coworker: I just uninstalled and installed the latest build. The service won't start, can you help?

    Me: sure, show me the issue

    He shows me the service manager throwing up an error when he tries to start the service.

    Me: let's take a look at the installation. Go to the install directory under Program Files.

    He goes to the installation directory... Under C:/Program Files(x86)...

    Me: why did you install the 32-bit version on a 64-bit machine?

    Coworker: no, it is the 64-bit version

    Me: ummm... No it's not... And you have the 64-bit JVM installed so it won't run.

    Coworker: no, it is the 64-bit version I installed. I'll show you the installer I ran.

    He shows me the installer clearly marked x86



    facepalm



    I just walked away.



    This is a "senior" software developer.



  • @JoeCool said:

    Under C:/Program Files(x86)...
     

    I love how Micrsoft decided to muck up everything with their transition to 64-bit.  Putting all old 32-bit code in a place that used to be called "Program Files" suddenly in "Program Files(x86)" and all the 64-bit stuff in "Program Files" is a good one.

    My company is suffering right now through Windows 64 bit transition issues... yes we're a little late to the party, but we develop embedded code, and some of those development tools do not like 64-bit... they're just now getting transitioned over.  It's also fun now that we have to support not only a dozen versions of third party tools, but now both their 32- and 64-bit versions!  Yes, part of the WTF is we don't just say "sorry we no longer support third party tools from 7 years ago."

    As an end user, I should not care if I'm installing or using a 64-bit or 32-bit application! I should not have to do anything special to install a 32-bit versus 64-bit application. The OS should make that transparent to me!




  • @too_many_usernames said:

    As an end user, I should not care if I'm installing or using a 64-bit or 32-bit application! I should not have to do anything special to install a 32-bit versus 64-bit application. The OS should make that transparent to me!

    You already don't. It's already transparent.



  • @too_many_usernames said:

    @JoeCool said:

    Under C:/Program Files(x86)...
     

    I love how Micrsoft decided to muck up everything with their transition to 64-bit.  Putting all old 32-bit code in a place that used to be called "Program Files" suddenly in "Program Files(x86)" and all the 64-bit stuff in "Program Files" is a good one.

    If your code depends on your Program Files folder being named "Program Files", your code is bad and you should feel bad.



  • @blakeyrat said:

    @too_many_usernames said:
    As an end user, I should not care if I'm installing or using a 64-bit or 32-bit application! I should not have to do anything special to install a 32-bit versus 64-bit application. The OS should make that transparent to me!

    You already don't. It's already transparent.

    You're right. It is transparent for the most part. What too_many_usernames is missing is the part where this is Java, and the 64-bit version needs a 64-bit jvm, while the 32-bit version requires a 32-bit jvm.

    The WTF is that as a senior software dev, he should know that x64 means 64-bit and x86 means 32-bit. (Well, unless it's marked x86-64)



  • @blakeyrat said:

    @too_many_usernames said:
    As an end user, I should not care if I'm installing or using a 64-bit or 32-bit application! I should not have to do anything special to install a 32-bit versus 64-bit application. The OS should make that transparent to me!

    You already don't. It's already transparent.

    Oh God. Install any old game or program on a 64 bit OS. Most of the time it's fine; other times, the game installer was written poorly on the (admittedly bad, but nevertheless reasonable at the time) assumption of the program directory location. BANG. Application crash of the worst kind, where you get no meaningful errors.



  • Right, but all you're saying is "software that doesn't follow the documentation of the OS maker will break when the OS changes", which is really a "duh". It doesn't add anything to the conversation.



  • @Master Chief said:

    @blakeyrat said:
    @too_many_usernames said:
    As an end user, I should not care if I'm installing or using a 64-bit or 32-bit application! I should not have to do anything special to install a 32-bit versus 64-bit application. The OS should make that transparent to me!

    You already don't. It's already transparent.

    Oh God. Install any old game or program on a 64 bit OS. Most of the time it's fine; other times, the game installer was written poorly on the (admittedly bad, but nevertheless reasonable at the time) assumption of the program directory location. BANG. Application crash of the worst kind, where you get no meaningful errors.

    I thought most programs would let me place themselves wherever I damn well please. How is assuming that the program is in "Program Files" any better than assuming that the program is on a C: drive, or in the main diirectory? Or hell, even assuming that there is a C: drive.

    Seriouly, the standard installer protocol is to let you choose an installation folder. And it very much doesn't have to, and never had to be "C:\Program Files".


  • Considered Harmful

    @Maciejasjmj said:

    @Master Chief said:
    @blakeyrat said:
    @too_many_usernames said:
    As an end user, I should not care if I'm installing or using a 64-bit or 32-bit application! I should not have to do anything special to install a 32-bit versus 64-bit application. The OS should make that transparent to me!

    You already don't. It's already transparent.

    Oh God. Install any old game or program on a 64 bit OS. Most of the time it's fine; other times, the game installer was written poorly on the (admittedly bad, but nevertheless reasonable at the time) assumption of the program directory location. BANG. Application crash of the worst kind, where you get no meaningful errors.

    I thought most programs would let me place themselves wherever I damn well please. How is assuming that the program is in "Program Files" any better than assuming that the program is on a C: drive, or in the main diirectory? Or hell, even assuming that there is a C: drive.

    Seriouly, the standard installer protocol is to let you choose an installation folder. And it very much doesn't have to, and never had to be "C:\Program Files".

    Worse are applications that default to C:\appname. I'm looking at you, Ruby.


  • @joe.edwards said:

    @Maciejasjmj said:
    @Master Chief said:
    @blakeyrat said:
    @too_many_usernames said:
    As an end user, I should not care if I'm installing or using a 64-bit or 32-bit application! I should not have to do anything special to install a 32-bit versus 64-bit application. The OS should make that transparent to me!

    You already don't. It's already transparent.

    Oh God. Install any old game or program on a 64 bit OS. Most of the time it's fine; other times, the game installer was written poorly on the (admittedly bad, but nevertheless reasonable at the time) assumption of the program directory location. BANG. Application crash of the worst kind, where you get no meaningful errors.

    I thought most programs would let me place themselves wherever I damn well please. How is assuming that the program is in "Program Files" any better than assuming that the program is on a C: drive, or in the main diirectory? Or hell, even assuming that there is a C: drive.

    Seriouly, the standard installer protocol is to let you choose an installation folder. And it very much doesn't have to, and never had to be "C:\Program Files".

    Worse are applications that default to C:\appname. I'm looking at you, Ruby.

    League of Legends installs to two separate drive-level folders.



  • Hard-coding to "C:/Program Files" has never been reasonable. The folder name has been localized in different language versions of Windows since Windows95 I think, so the application could never have worked on Spanish/German/French/Dutch/etc. computers.



  • @Maciejasjmj said:

    @too_many_usernames said:

    @JoeCool said:

    Under C:/Program Files(x86)...
     

    I love how Micrsoft decided to muck up everything with their transition to 64-bit.  Putting all old 32-bit code in a place that used to be called "Program Files" suddenly in "Program Files(x86)" and all the 64-bit stuff in "Program Files" is a good one.

    If your code depends on your Program Files folder being named "Program Files", your code is bad and you should feel bad.

    It doesn't, and I never said it did.



  •  Even the default for an install should not be set to "C:\Program Files"....it should be set to the proper environment variable!

    For a 64 bit Environment: 

    ProgramFiles=C:\Program Files
    ProgramFiles(x86)=C:\Program Files (x86)
    ProgramW6432=C:\Program Files

     



  • @TheCPUWizard said:

     Even the default for an install should not be set to "C:\Program Files"....it should be set to the proper environment variable!

    For a 64 bit Environment: 

    ProgramFiles=C:\Program Files
    ProgramFiles(x86)=C:\Program Files (x86)
    ProgramW6432=C:\Program Files

     

    That IS the way it is set up.



  • @TheCPUWizard said:

     Even the default for an install should not be set to "C:\Program Files"....it should be set to the proper environment variable!

    For a 64 bit Environment: 

    ProgramFiles=C:\Program Files
    ProgramFiles(x86)=C:\Program Files (x86)
    ProgramW6432=C:\Program Files

     

    I just want to know which nuff-nuff thought ProgramFiles(x86) was a better name for an environment variable than ProgramFilesX86. Obviously never written a script in his life.



  • Meanwhile, back in the real world, Blakeyrat is correct.

    Why would you hand-craft your own installer? You would use nulsoft or installshield or visual studio setup (which is installshield) so that your program code is placed in the program files folder. The installer and Windows will take care of placing that in "x:\program files", "program files (x86)", etc. for you

    Note the x:\ too... I have come across machines where the system disk is D: or some other letter (quite why is another WTF) and this is just one more reason why you don't wanna be guessing at "c:\program files\"

    I mean, come on. Installing Windows apps in a setup or msi is a well-understood problem today - why would you want to be trying to figure all that shit out for yourself?

    Oh, and finally, I personally think that the "Program Files" / "Program Files (x86)" solution, complete with automatic redirection for 32bit apps, was a pretty decent solution.



  • Besides, if you're not using the English version of Windows, your Program Files folder has never been named "Program Files" to begin with. So it's not like it's a new thing.



  •  hey guys,i thought i should let you know:

    If your application relies on being installed in C:\Program Files then it is badly coded. 

    Just thought i should add that just in case you didn't know.



  • I think you guys have missed my point. First, it's not our application that is having problems*, it's the third-party tools we use. Heck, some of the old versions still fall over if you have spaces in pathnames, so it's not just the issue with 64-bit. (We actually had to install DOSbox to get an old compiler to work properly. Madness.)

    Second, if the old "32-bit" way of doing things was "Folder A", it's an idiotic decision to say "going forward, new 64 bit things are in 'Folder A' and we're going to start putting 32 bit things in 'Folder B' " - why would you force old stuff to move, instead of putting new stuff in a new place?

    Third - why would 64-bit and 32-bit stuff need to be in different places anyway? That is - why would a folder location convention even be established for such a thing? This is arguably the main WTF in my mind.

    *Our "application" is code for an embedded device, which is micro-controller specific - so our "apps" are just .a files for our target. They don't have any relation to what the host operating system bit-width.


  • Discourse touched me in a no-no place

    @too_many_usernames said:

    [W]hy would 64-bit and 32-bit stuff need to be in different places anyway? That is - why would a folder location convention even be established for such a thing? This is arguably the main WTF in my mind.
    This one puzzled me too. Libraries I could understand, but executable applications?



  • @blakeyrat said:

    @too_many_usernames said:
    As an end user, I should not care if I'm installing or using a 64-bit or 32-bit application! I should not have to do anything special to install a 32-bit versus 64-bit application. The OS should make that transparent to me!

    You already don't. It's already transparent.

     

    Funny thing, since there are 64 bits Windows around, I don't remember to have ever installed some piece of software that I didn't have to choose between the 32 or 64 bits versions.

     For what software it's transparent, Blakey?



  • @JoeCool said:

    @TheCPUWizard said:
    Even the default for an install should not be set to "C:\Program Files"....it should be set to the proper environment variable!

    For a 64 bit Environment: 

    ProgramFiles=C:\Program Files
    ProgramFiles(x86)=C:\Program Files (x86)
    ProgramW6432=C:\Program Files

    That IS the way it is set up.

    No it's not. The environment variables are only there for compatibility. Use the actual API call.



  • @Mcoder said:

    @blakeyrat said:

    @too_many_usernames said:
    As an end user, I should not care if I'm installing or using a 64-bit or 32-bit application! I should not have to do anything special to install a 32-bit versus 64-bit application. The OS should make that transparent to me!

    You already don't. It's already transparent.

     

    Funny thing, since there are 64 bits Windows around, I don't remember to have ever installed some piece of software that I didn't have to choose between the 32 or 64 bits versions.

     For what software it's transparent, Blakey?

    Arch Linux has a pretty transparent installer. It starts in 32 bit mode and then checks your processor to see if it can switch to 64 bit mode. I think that's what blakeyrat was talking about.



  • @dkf said:

    @too_many_usernames said:
    [W]hy would 64-bit and 32-bit stuff need to be in different places anyway? That is - why would a folder location convention even be established for such a thing? This is arguably the main WTF in my mind.
    This one puzzled me too. Libraries I could understand, but executable applications?

    What if you need both the 32-bit and 64-bit version of the application? And other applications on your system depend on one or the other version?



  • @Mcoder said:

    For what software it's transparent, Blakey?

    Really? I think I've been asked once, and it was Java bullshit. Java's written by idiots.

    Therefore, I guess you install only software written by idiots. Or you yourself are an idiot, and go way out of the way to find the "advanced" installer page that lets you select between the two. Idiot + Idiot = Megaidiot




  • @blakeyrat said:

    @JoeCool said:
    @TheCPUWizard said:
    Even the default for an install should not be set to "C:\Program Files"....it should be set to the proper environment variable!

     

    For a 64 bit Environment: 

    ProgramFiles=C:\Program Files
    ProgramFiles(x86)=C:\Program Files (x86)
    ProgramW6432=C:\Program Files

    That IS the way it is set up.

    No it's not. The environment variables are only there for compatibility. Use the actual API call.

    100% agreement that the API is (much) better than the environment variable. I still maintain that the environment variable is significantly better than a friggin hard coded literal! 



  • @blakeyrat said:

    @Mcoder said:
    For what software it's transparent, Blakey?

    Really? I think I've been asked once, and it was Java bullshit. Java's written by idiots.

    Therefore, I guess you install only software written by idiots. Or you yourself are an idiot, and go way out of the way to find the "advanced" installer page that lets you select between the two. Idiot + Idiot = Megaidiot

    There are two kinds of software:

    1. Software that is only built in 32bit mode
    2. Software that has multiple installers, one for each platform


  • Superuser.com: why-does-64-bit-windows-need-a-separate-program-files-x86-folder

    "The real mess about the 64/32bit differentiation is that /Windows/System32 contains 64bit content, while /Windows/SysWOW64 contains the 32bit stuff… – poke" This always confused me as well.



  • @Ben L. said:

    There are two kinds of software:

    1. Software that is only built in 32bit mode
    2. Software that has multiple installers, one for each platform

    Jesus Christ. If Juniper can write an installer for Network Connect that works on both 32-bit and 64-bit computers from a single EXE, and it installs DRIVERS and other NASTY STUFF, and Juniper's software is COMPLETE AWFUL BULLSHIT IN EVERY OTHER WAY... if they can pull it off, anybody can.

    Stop making excuses for shitty programmers writing shitty programs.



  • @blakeyrat said:

    @Ben L. said:
    There are two kinds of software:

    1. Software that is only built in 32bit mode
    2. Software that has multiple installers, one for each platform

    Jesus Christ. If Juniper can write an installer for Network Connect that works on both 32-bit and 64-bit computers from a single EXE, and it installs DRIVERS and other NASTY STUFF, and Juniper's software is COMPLETE AWFUL BULLSHIT IN EVERY OTHER WAY... if they can pull it off, anybody can.

    Stop making excuses for shitty programmers writing shitty programs.

     

     Do you often enjoy downloading applications that are doubled in size for no effing reason whatsoever?

    The easy version is: ->Go to Website -> Website queries which OS you are running (32-bit/64-bit) -> Offers you to download fitting .exe -> You can choose other if you absolutely need to.

    Sometimes I think you people enjoy picking the most stupid version of yourself you could be ("I don't wanna figure out which architecture I am running") and then try to build solutions based on that caricature.

     



  • @blakeyrat said:

    @JoeCool said:
    @TheCPUWizard said:
    Even the default for an install should not be set to "C:\Program Files"....it should be set to the proper environment variable!

    For a 64 bit Environment: 

    ProgramFiles=C:\Program Files
    ProgramFiles(x86)=C:\Program Files (x86)
    ProgramW6432=C:\Program Files

    That IS the way it is set up.

    No it's not. The environment variables are only there for compatibility. Use the actual API call.

    How the fuck would you know how the installer works? It's done using Basic MSI from InstallShield. It uses the standard mechanism. Which means it doesn't hardcode the location. It uses variables within installshield which map exactly how was said above.


  • ♿ (Parody)

    @blakeyrat said:

    Jesus Christ. If Juniper can write an installer for Network Connect that works on both 32-bit and 64-bit computers from a single EXE, and it installs DRIVERS and other NASTY STUFF, and Juniper's software is COMPLETE AWFUL BULLSHIT IN EVERY OTHER WAY... if they can pull it off, anybody can.

    They can't pull it off. I'm not sure where this leaves us.



  • @fire2k said:

    @blakeyrat said:

    @Ben L. said:
    There are two kinds of software:

    1. Software that is only built in 32bit mode
    2. Software that has multiple installers, one for each platform

    Jesus Christ. If Juniper can write an installer for Network Connect that works on both 32-bit and 64-bit computers from a single EXE, and it installs DRIVERS and other NASTY STUFF, and Juniper's software is COMPLETE AWFUL BULLSHIT IN EVERY OTHER WAY... if they can pull it off, anybody can.

    Stop making excuses for shitty programmers writing shitty programs.

     

     Do you often enjoy downloading applications that are doubled in size for no effing reason whatsoever?

    The easy version is: ->Go to Website -> Website queries which OS you are running (32-bit/64-bit) -> Offers you to download fitting .exe -> You can choose other if you absolutely need to.

    Sometimes I think you people enjoy picking the most stupid version of yourself you could be ("I don't wanna figure out which architecture I am running") and then try to build solutions based on that caricature.

     

    This. And it is not the standard way to do things. Maybe Juniper software is shitty because they don't follow standards.


  • Discourse touched me in a no-no place

    @fire2k said:

    Do you often enjoy downloading applications that are doubled in size for no effing reason whatsoever?
    For lots of applications, the platform-specific parts are only a small fraction of the overall size. Serving up a universal package that does the right thing when it encounters the system on which it is being installed instead of having to have the user guess it right, well that makes a horribly large amount of sense to me.

    It's just bandwidth. Or do you still pay by the megabyte where you are?



  • @dkf said:

    @fire2k said:
    Do you often enjoy downloading applications that are doubled in size for no effing reason whatsoever?
    For lots of applications, the platform-specific parts are only a small fraction of the overall size. Serving up a universal package that does the right thing when it encounters the system on which it is being installed instead of having to have the user guess it right, well that makes a horribly large amount of sense to me.

    It's just bandwidth. Or do you still pay by the megabyte where you are?

    I pay by the second for my not-being-dead.


  • Garbage Person

    @blakeyrat said:

    @Ben L. said:
    There are two kinds of software:

    1. Software that is only built in 32bit mode
    2. Software that has multiple installers, one for each platform

    Jesus Christ. If Juniper can write an installer for Network Connect that works on both 32-bit and 64-bit computers from a single EXE, and it installs DRIVERS and other NASTY STUFF, and Juniper's software is COMPLETE AWFUL BULLSHIT IN EVERY OTHER WAY... if they can pull it off, anybody can.

    Stop making excuses for shitty programmers writing shitty programs.

    On the flipside of Blakeyrants' "Run anywhere" world, I recently gained control of a vast library of C# services. They all compile as "Any CPU", which basically means the JIT compiler will 'Do the right thing' on the system executing the code.

    My predecessor, faced with 'OH CRAP OUR APPSERVERS ARE OVERLOADED' took a spare VM and loaded up the services and switched it on.

    Difficulty: The spare VM was 64-bit Windows. The prod cluster predates that technology. Turns out 'do the right thing' doesn't include 'make sure referenced libraries are actually capable of running in the mode you want to run in'. That was a fun day when that server joined the cluster.

     

    Jerkfuck third party developers, for whatever reason, insist on delivering either-or builds of their libraries, even when they're not depending on any architecture-specific underlying language. So if you depend on one of those, you are literally just fucked out of an otherwise very damned nice language feature. Even opensource binaries are delivered either-or. If you want both, you have to build it yourself.

    My first act: Start culling libraries written by morons.
    My second act:  Start the glacier melting on the process of getting a 64-bit dev server so we can test this shit.

     



  • @dkf said:

    For lots of applications, the platform-specific parts are only a small fraction of the overall size.

     

     And for lots they aren't. If a 32-bit library and a 64-bit library have the same functionality a universal binary would still double the size. Was there a point here?

    @dkf said:

    It's just bandwidth. Or do you still pay by the megabyte where you are?

     

    It's nice that you are living in downtown silicon valley, but I have a 6mbit/s connection, so downloading 4 freaking gigabytes for no reason will annoy me. The limiting factor is my time, which still will equate to costs if I could have been using that bandwidth and time otherwise.

     



  • @blakeyrat said:

    Therefore, I guess you install only software written by idiots.
     

    Let me see... Java (actualy, anything by Oracle), anything by Microsoft (you have to make sure you get out of the store with the right Office box - can it get more outdated than that?), any anti-virus, stuff from Auto-desk, anything from Adobe...

    Looks like you are right.

     


  • Considered Harmful

    @Mcoder said:

    @blakeyrat said:

    Therefore, I guess you install only software written by idiots.
     

    Let me see... Java (actualy, anything by Oracle), anything by Microsoft (you have to make sure you get out of the store with the right Office box - can it get more outdated than that?), any anti-virus, stuff from Auto-desk, anything from Adobe...

    Looks like you are right.

     

    According to blakey, all software since classic Mac is written by idiots.


  • Discourse touched me in a no-no place

    @Weng said:

    My first act: Start culling libraries written by morons.
    Starting from a blank slate then?



  • @Mcoder said:

    (you have to make sure you get out of the store with the right Office box - can it get more outdated than that?)

    You are a liar.


  • Discourse touched me in a no-no place

    @fire2k said:

    It's nice that you are living in downtown silicon valley
    San Jose's interesting to visit, but I wouldn't want to live there. I'll stay here, with my 50Mb bargain basement connection in Yurrp.@fire2k said:
    I have a 6mbit/s connection
    I have a very small violin here. Do you want a very sad song playing? (Seriously, while some code systems are a majority of platform-specific code, most aren't and have a lot of other stuff besides. At some point, it makes sense to use a larger packaged size than to support every damn platform combo as a separate download for users to fuck up.)



  • @fire2k said:

    I have a 6mbit/s connection

    We must have the same ISP!



  • @dkf said:

    @fire2k said:
    It's nice that you are living in downtown silicon valley
    San Jose's interesting to visit, but I wouldn't want to live there. I'll stay here, with my 50Mb bargain basement connection in Yurrp.@fire2k said:
    I have a 6mbit/s connection
    I have a very small violin here. Do you want a very sad song playing? (Seriously, while some code systems are a majority of platform-specific code, most aren't and have a lot of other stuff besides. At some point, it makes sense to use a larger packaged size than to support every damn platform combo as a separate download for users to fuck up.)
     

     Yes, I would love a "very sad song playing".

     Anyway "every damn platform combo" boils down to two platforms: x86 and x64. And since the majority of code compiles to one of those two platforms in a fixed manner, saying that most code systems are platform independend is a blatant lie. They can be compiled on multiple platforms. 3dsMax for example, has 2GB of compiled code(.dlls and .exes) that strictly depends on your target arch, and already is a 8GB-setup (+ some shared Autodesk dependencies that would be installed with other Autodesk software anyway). Why the eff should that be made into a 10GB setup? And what exactly was the problem with the website autodetermining your target arch?



  • @fire2k said:

    And what exactly was the problem with the website autodetermining your target arch?

    Well, what happens if you're going to install a program on a computer without an internet connection that happens to be a different arch than the one you're downloading it on?



  • @Ben L. said:

    @fire2k said:
    And what exactly was the problem with the website autodetermining your target arch?

    Well, what happens if you're going to install a program on a computer without an internet connection that happens to be a different arch than the one you're downloading it on?

     

     Installing a 32-bit application on a 64-bit OS: Nothing, the application installs and works. I am currently not aware of any consumer-applications that need more than 4Gigs of memory, so nothing breaks for them (unless the application is depending on hardcoded paths, in which case you probably won't need what they have to offer).

     Installing a 64-bit application on a 32-bit OS: The application crashes and tells you what is wrong. You can now work specifically on what went wrong the first time.

    Worst case is you redownloading the setup for a different arch, which still equates to only a small increase in size to universal binaries.



  • @blakeyrat said:

    @Mcoder said:
    (you have to make sure you get out of the store with the right Office box - can it get more outdated than that?)

    You are a liar.

    Never bought Office in a box, but Office definitively has some problems with 32-bit vs 64-bit versions. I had OneNote (64bit) installed on a laptop (downloaded from MSDNAA/Dreamspark/whatever it's called these days), and then was forced to install Powerpoint for some work stuff. Work provided me with a 32-bit Office, which upon installation promptly informed me that it won't continue because it detected a 64-bit Office component (i.e., OneNote) on the machine.

    Resolution: uninstall 64-bit OneNote, install 32-bit Powerpoint and OneNote. Annoying at worst, but still, one wonders what's preventing these being installed side by side...



  • @Maciejasjmj said:

    Besides, if you're not using the English version of Windows, your Program Files folder has never been named "Program Files" to begin with.

    Dutch-language Windows 95:



  • Christ. This forum is supposed to be for software developers yet we have people posting who think that a 64bit application is literally twice the size of a 32bit one because, durr, 64 is twice as big as 32.

    Even if they were (they're not) the bandwidth and/or disk space is cheap. The shit about a 10GB setup is pure bollocks - what app comes with a 10GB setup? And what media does it ship on? 10,000 floppies?

    Windows actually does a pretty good job of coping with 32bit and 64bit apps (on a 64bit machine) and it all "just works(tm)". Assuming, of course, that you wizard programmers use a grown-up installer or manage to read the installer API manuals.

    Anyone who can't figure out how to sort out an installer for their app (and get it under 10GB) is the real WTF


  • ♿ (Parody)

    @skotl said:

    Christ. This forum is supposed to be for software developers yet we have people posting who think that a 64bit application is literally twice the size of a 32bit one because, durr, 64 is twice as big as 32.

    Do we expect forum members to have the reading comprehension skills to know that the "doubled in size" claim was due to having both 32 and 64-bit code to download?

    Asking for a friend.


Log in to reply