Slashdot Mirror
Why Does Microsoft Still Offer a 32-bit OS? (backblaze.com)
Brian Wilson, a founder of cloud storage service BackBlaze, writes in a blog post: Moving over to a 64-bit OS allows your laptop to run BOTH the old compatible 32-bit processes and also the new 64-bit processes. In other words, there is zero downside (and there are gigantic upsides). Because there is zero downside, the first time it could, Apple shipped with 64-bit OS support. Apple did not give customers the option of "turning off all 64-bit programs." Apple first shipped 64-bit support in OS X 10.6 Snow Leopard in 2009. This was so successful that Apple shipped all future Operating Systems configured to support both 64-bit and 32-bit processes. All of them. But let's contrast the Apple approach with that of Microsoft. Microsoft offers a 64-bit OS in Windows 10 that runs all 64-bit and all 32-bit programs. This is a valid choice of an Operating System. The problem is Microsoft ALSO gives customers the option to install 32-bit Windows 10 which will not run 64-bit programs. That's crazy. Another advantage of the 64-bit version of Windows is security. There are a variety of security features such as ASLR (Address Space Layout Randomization) that work best in 64-bits. The 32-bit version is inherently less secure. By choosing 32-bit Windows 10 a customer is literally choosing a lower performance, LOWER SECURITY, Operating System that is artificially hobbled to not run all software. My problem is this: Backblaze, like any good technology vendor, wants to be easy to use and friendly. In this case, that means we need to quietly, invisibly, continue to support BOTH the 32-bit and the 64-bit versions of every Microsoft OS they release. And we'll probably need to do this for at least 5 years AFTER Microsoft officially retires the 32-bit only version of their operating system.
You can't collect surveillance data on people with older computers if you aren't offering them an OS that will run on it that can collect surveillance data for you, that's why.
I don't know why they offer a 32 bit still, but it sure is annoying
my gaming machine threw a rod or something, I had to re-install, but bla bla bla the only license I could find in my big bin o' parts was for 32 bit windows 7, but they offered free win10 upgrade so what the hell I tried.
Anyway long story short, even though I had 64 bit selected it ended up installing 32 bit windows 10.
I ended up using my stupid 32 bit windows 10 to download 64 bit windows 10 installation media after extracting my CD-key from the registry I had to wipe the computer for like the 5th time in a row, and re-install 64 bit from scratch via a thumb drive.
Some computers still run on 32 bit processors. In many businesses you have the need to update software for security reasons but are unable to update hardware.
For some people, 4096MB *are* enough. And why buy a new computer when your old is working fast enough for you.
I installed it on my 10 year old Pentium M for my garage music. Worked great.
So you're saying that Microsoft should make Windows OS X be 64-bit only because Apple did so?
And because doing so would make sense?
Are those really good reasons to make such a change? Did anyone ask marketing for their input?
I'll see your senator, and I'll raise you two judges.
and Apple doesn't.
Now you can run old custom 32 bit programs in a newer 64 bit OS and mostly it will run fine, but why replace "100% guaranteed to run" with "most likely will run"? Especially with old funky device drivers that were fine-tuned for the old setup?
64-bit versions of Windows do not support 16-bit components, 16-bit processes, or 16-bit applications
That's why. There is still a TON of legacy apps out there in use that won't function properly. I don't have that problem. But it exists. And that's only one of the reasons. I'm sure there are other reasons.
"A plan fiendishly clever in its intricacies"- Homer Simpson
SCADA and other legacy industrial applications that still require the use of RS232
Life is not for the lazy.
Microsoft doesn't offer 32- and 64-bit Windows in the same installer like Apple?
Or Microsoft haven't abandoned 32-bit processors as Apple have done in 2014?
Or Microsoft isn't Apple?
It's not rocket science - many people still use PCs that have 32-bit processors.
This sig left unintentionally blank.
Some software packages (stupidly) check to see if a WIndows OS is 32 bit or 64 bit before running or installing and if it's not 32 bit, they don't start. How do I know this? I know a person who runs their business on an outdated software package with exactly that limitation, which is why upgrading their office network was a hell of a challenge to ensure we got 32 bit versions of Win 7 Pro when we bought the equipment.
Why don't they get a new version? Because the company that makes the software is out of business
Why don't they use something else? Because they LIKE this package and for what it does, it works well.
Also, don't device drivers for 64-bit Windows need to be signed? I.e. they need to be current device drivers in active development, which won't be the case for a lot of legacy hardware.
Breakfast served all day!
When you bought a 2 million dollar confocal microscope in 2000 and it came with a PC with a 32 bit processor with a bunch of custom controller hardware in it running windows XP, you just keep using that hardware because it's the only way to get data off your 2 million dollar microscope and there is no way to upgrade without junking the microscope because the manufacturer has moved on and there is no support for that 17 year old hardware other than to continue to use the particular machine they gave you back in 2000
That's the general answer. There is also a very specific answer in the case of Windows: 64-bit editions of Windows cannot run Win16 apps. There are still (FML) significant chunks of Win16 code out there, which everyone can agree is a pain in the ass but it's still a reality for some verticals. There may be some other compatibility considerations, too - right now I'm too drunk to check, but DOS emulation is different between the 32 and 64 bit editions.
Because it is inconvenient for us to support an older OS, fuck everyone who has older hardware! Our use case is the ONLY use case!
You can still install the drivers. You just need to set the permission level using this:
/set nointegritychecks ON
bcdedit
So, can anybody tell me why a 64-bit OS can't support 16-bit software? Is this some sort of laziness or artificial limitation imposed by Microsoft, or perhaps something caused by the 64-bit mode in the CPU itself?
"-1 Troll" is the apparently the same as "-1 I disagree with you."
The 64 bit footprint is bigger.
I have a cheap-o Asus tablet hybrid thing. It's only about 3 years old. Still works. The CPU is 64-bit in theory, but the EFI bios only allows 32-bit Windows. It's tied to the license key or something.
Installing software on the flash of this device is _tight_ and with 4GB or RAM there isn't a lot of real advantage to 64-bit Windows anyway.
I think this article might have been written by someone who only gets use cases for modern high-performance machines.
Does one have to wipe the system and reinstall everything? or can you over-install the 64 bit OS and leave everything else intact?
Apple's 64-bit OS transition started in 2004, not 2009.
I can't tell if most Slashdotters are teenagers, or live in a single office room and never venture outside. Because there are TONS OF BUSINESSES that still use legacy software A DECADE out of "support." The people that wrote the software have left the company. There's no documentation. And the software _still_ _works_.
Whenever you replace software, you have to understand it (a huge task), you have to re-implement it (a huge task), you have to transition it from old-to-new without corrupting data or interrupting business. (sometimes a huge task.)
I'm currently updating a .NET 1.1 / VS2003 application. It's a pain in the ass and even throwing C++ EXCEPTIONS even though its a C# program. A google of the error message returns... no results. Yay!
Meanwhile, in the last three years I've met not one, but TWO, different companies that still run their internet-connected AS/400 (Google it.) in a live, critical environment. And last year I found the reason a lab was running so slow... it funneled everything (including 150MBit wireless) through a 10 MBit ethernet... hub. (Not a switch.)
Legacy exists everywhere. It's a real problem. Hell, look at the B-52's that were designed in 1955, and we're STILL FLYING THEM as part of our essential air force. (I'm guessing because they cost a 100x less to fly than the billion dollar B-2's.) When was the last time you went to Radioshack (ha!) and bought a bunch of VACUUM TUBES to fix your multi-million dollar airplane. Well, the military has that exact problem.
I'm in the private sector and I still see the software equivalent every month.
Believe it or not, there are businesses/people out there that still rely on 16 bit apps! They WILL run under Win32, but not Win64
Windows only thunks back one level
-- 73 de KG2V For the Children - RKBA! "You are what you do when it counts" - the Masso
Because in reality business, government and other large customers have an enormous sunk cost in legacy applications that don't run on 64 bit windows. While 16 bit applications won't run at all, a very large number of 32 bit applications also won't run properly on 64 bit windows.
These applications run everything from factory machines to payroll and you can't simply replace them with a visit to Amazon. Replacing them can easily cause a chain reaction of expenses (hardware, software, machines, programming time, training and migration). I've seen platforming changes that cost millions of dollars, without any of that going to license costs.
The vast majority of users aren't technical and see their computer as nothing more than a tool. Why pay large amounts of money to replace a tool that works without perceivable benefit?
PowerMac G5s shipped in 2003. 64-bit kernel shipped in Panther, 2003. 64-bit userspace shipped in Tiger, 2005.
At some point, you have to start asking whether the 16-bit app support exists because of the legacy apps or whether the lack of 32-bit versions of those apps is because the 16-bit app support exists.
To put some hard numbers on this, Windows 95 brought 32-bit support to the platform in 1995. So all the 16-bit software out there is 22 years old. Continuing to maintain an entire operating system platform to support software that was written before this year's college grads were even born is just plain insane. That's way too much effort for what should be almost zero benefit.
Killing support for 16-bit software will force the manufacturers, assuming they are even still in business after more than two decades, to update their software to something remotely current. And if the manufacturers no longer exist, then if there's still enough value in the software, someone will take the time to reverse engineer it and write a 32-bit version, or write code that translates the old data files to work with a modern app, or write modern drivers for old hardware or whatever. And if there isn't enough value in that software, it will wither and die. And that's okay.
That said, it could reasonably be argued that they should have done this fifteen years ago, and that at this point, so many of the companies have ceased to exist that the economic impact will be huge. If that is the case, then the right fix is to run a twenty-five-year-old copy of Windows 3.1 in a VM with just enough hardware access to do the job, then walk away.
Check out my sci-fi/humor trilogy at PatriotsBooks.
Some software doesn't run on 64 bit, a bit of a problem with the Windows legacy is that all forms of API, both public and private have to be continue to be supported, just like Itanium and SPARC, PPC or Alpha for certain Linux and Unix distro.
Another issue is licensing, especially Database and data processing from big companies like IBM, Oracle but a lot of niche closed source software has the same problem, 64 bit versions simply cost more because back in the day, that's how you got access to more than 4GB of RAM.
Then there is Office. Doesn't work well on 64 bit machines. Works fine on 32 bit.
Custom electronics and digital signage for your business: www.evcircuits.com
If you think that's bad, look carefully at the installer for MS Office 2016/365. If you do nothing, it still installs the 32-bit version by default.
You can see Microsoft's own 32 vs 64 guide for Office here:
https://support.office.com/en-us/article/Choose-between-the-64-bit-or-32-bit-version-of-Office-2dee7807-8f95-4d0c-b5fe-6c6f49b8d261
The 2013 version of that guide still recommends 32-bit for most people, and I believe until recently the 2016 version did the same.
First we bitch at Apple because they stopped supporting 32-bit machines after 10.8. Now we bitch at Microsoft because they *still* support 32-bit machines.
Please make up your mind, people.
I think you found the answer. Where I work there are still applications will run on 32-bit and not 64-bit, although technically that's speaking of Windows 7 as OS. Not sure the software in question would run windows 10, 32 or 64-bit.
I did buy some windows tablets and a small Raspberry Pi-sized device that run Windows in the last couple years (something about sub-$100 windows devices, I don't know, novelty I guess). The Raspberry Pi-sized device identifies the Atom as a "64-bit CPU" but for whatever reason the UEFI has locked it to 32-bit only operating systems. Which does conveniently prevent Windows 7 from being installed on the device (32-bit 7 doesn't do UEFI while 64-bit does). Maybe I could do some kind of GRUB magic, I don't know. The devices have as little as 16 gigs of storage or sometimes 32gigs with 2 gigs of RAM so I don't feel like I'm missing out on that much with the limit of 32-bit.
So another reason could be there's still hardware out there that literally can't run 64-bit windows that are still technically within the support time frame and/or under warranty. Apple doesn't have to worry about generic off-brand Chinese OEMs using weird UEFI firmware/SoC combos but technically Microsoft does...
"UNIX is very simple, it just needs a genius to understand its simplicity." -Dennis Ritchie
The CPU still starts up in 8088 8 bit mode. The problem is that MS largely doesn't care about its legacy API. They don't reimplement them or improve them (when was the last time they improved or even touched the COM interfaces or old Win16 macros?), they just build more on top and when it breaks they say: just use the old version.
Custom electronics and digital signage for your business: www.evcircuits.com
Like Toshiba, offering 64-bit systems but hardlocking them to 2GB RAM in bios.
Still waiting on Serviscope_minor to wake up to fucking reality and realize that Jessica Price isn't going to fuck him.
So you need a system wide change to elevate the permissions temporarily? Does it work when you turn it back on? Why does Windows not have sudo?
Custom electronics and digital signage for your business: www.evcircuits.com
Some software just won't run in a 64 bit environment, regardless of WoW64 and thunking. Most of the software that is the most rigidly tied to a 32 bit environment is the kind of software that is also the most mission critical. The kind of software that operates radar ARPAs, hospital respirators, navigation systems, and MRIs. Apple, as pretty as it is, just doesn't have the presence in the industrial side of things that Microsoft does - in fact they don't have any industrial presence to speak of. As a desktop only computer, they are more free to adopt new OS features that render old software incompatible. Many beloved programs from the past have been rendered inoperable by a MacOS upgrade. While inconvenient for the user, it is hardly catastrophic.
Now, no one is going to perform an OS upgrade on an existing MRI of course. But there are many reasons why an MRI vendor would want to bring out a new model with a new (perhaps more secure) version of Windows, but where the software is still tied to 32 bit. Industrial software is far less agile. You just can't recompile for 64 bit, it has to go through very strict verification and rigid change control. That kind of process takes years, and costs far more than most software porting. What about that 80 year old who has had a forgotten metal bit in his shoulder for 40 years who is put into an MRI to have that bit forcibly ripped out of his body by because the magnetic flux feedback detection didn't work properly when the 32-bit driver for it was mis-ported to 64 bit?
So while Microsoft is hardly a company I regularly defend, in this case you just can't compare a company that only puts out pretty ergonomic desktop machines and keeps draconian control of hardware to the extent that you really can't use the OS anywhere else, and a company that produces OSes for everyone's hardware that ranges from embedded microcontrollers, to warship navigation systems, to tablets.
When Intel CPUs are operating in long mode (x64 code execution), they cannot be switched to 16 bit real-mode compatibility mode.
To use 16 bit real-mode compatibility mode, the CPU must be running in legacy mode (x64 support disabled).
The windows 16 bit API would occasionally require real mode coding, even though the bulk of operations were done in 16 bit protected mode. As a result, this cannot be executed natively on a x64 CPU which has been booted into long mode, and would require code emulation which was not considered a sensible design feature, especially as virtualization technology meant that on the rare occasion when 16 bit compatibility was required, you could simply run a 32 bit guest OS in legacy mode on a virtualized CPU.
Since you seem to have some clue about this.....
It seems to me that every x86-64 CPU also has virtualization. Do you think that it might be possible to use virtualization "under the hood" to get 16-bits to run without having to install a 2nd OS? In other words: use virtualization without the user knowing or caring that virtualization is even being used.
"-1 Troll" is the apparently the same as "-1 I disagree with you."
If they've got to Google the AS/400, then maybe Slashdot isn't really the best place for them to visit/comment?
"So long and thanks for all the fish."
Why does Microsoft still sell 32 bit versions of Windows? Because there is a demand for it. Some customers have a need for a 32 bit version of the OS, for either legacy hardware or software (or both). I don't work at Microsoft, but I would guess that the demand for a 32 bit version of the software is greater than the cost of producing and maintaining it. Therefore, they sell it.
As the market for a 32 bit version of their OS dwindles, it will probably be retired when they don't make money by selling it. Until then, I would guess that they will keep producing it, since they want to, you know, make money by selling a product that people want to buy.
simple legacy apps and legacy hardware. shit ton of both still around. Using apple as an example is braindead, apple don't have a vast enterprise footprint with billions of lines of code in legacy apps.
Siemens.
No - some are the people that write software that is so shit it gets chucked after 6 months. They find it hard to imagine software that is still useful after a year.
Probably also children of the tosspots who wrote shareware programs that failed to install and wondered why no one upgraded to the paid version.
Sent from my ASR33 using ASCII
So you need a system wide change to elevate the permissions temporarily? Does it work when you turn it back on? Why does Windows not have sudo?
It does, sorta: UAC. Either way it does not apply in this case. This change isn't a privilege elevation, it turns off a security feature that requires drivers to be signed. It's designed on purpose to be non-trivial to do to discourage using it.
I browse on +1 so AC's need not respond, I won't see it.
I believe the real reason is Microsoft's plan to offer Real Windows on new ARM processor machines via x86 (32-bit) emulation. See https://www.extremetech.com/co... Microsoft can't let 32-bit die less this new emulation project become become another Windows RT. Perhaps this will change if and when they can emulate 64 bits...
Hardware.
..is a single byte that prefixes the instruction. Other than that the instructions are identically encoded. The prefix byte says "no not this mode dummy, the other mode!"
The CPU shares the same flags and switches between both 16-bit and 64-bit mode. For instance there is an instruction prefix that indicates if the next instruction should use the current mode's word size or the word size of "the other mode."
The difference between...
add eax, ebx (32-bit)
and both add rax, rbx (64-bit) and add ax, bx (16-bit)
So here we are, stuck with "only" 2 modes to switch between. Amazingly some people complain...
"His name was James Damore."
The other comments here have already answered why MS still offers a 32-bit OS - not a hard question.
What strikes me as weird is why many Linux distros today aren't offering a 32-bit OS. The next Debian release won't have a 32-bit version, for example. They should know that a good chunk of their users are computer hobbyists who run it on older, repurposed hardware. And not as old as you might think, Intel was shipping 32-bit Atoms through 2010 at least. I have one I'm using to this day as a low-power fileserver/seedbox/irc-bouncer.
Really odd to see them drop x86 support when they support other weird architectures I haven't seen since the 90s, or ever. Does anyone know why?
These arent "apps" he is talking about.
The "solution" of course is to buy new industrial equipment to replace the old that you are controlling with that 16-bit computer. So it''ll only cost a few hundred grand at best to move off of that 16-bit CNC setup. Not a big deal at all, right? Then they can run windows 10 too... thats an awesome operating system for industrial equipment. Honest.
"His name was James Damore."
Heck I have an AS/400 in my server room right now.
Sorry, teleporters just kill you and then make a copy. A perfect, soul-less copy.
Most legacy 16bits applications should have died a long time ago, EXCEPT the 16bits games ! There are tons of old but excellent 16bits games that many of us still want to play and which have never been ported to 32bits. ...and that includes old games from Microsoft : Remember the Windows Entertainment Packs (WEP) 1 and 2 ?
Anyway there is also an alternative : running a 32bits OS (like an old version of XP) in a virtual machine. Under VirtualBox, I use my XP machine for games exclusively.
Yes you do need a system wide change. And when you make that change, Windows will put a "Test mode" watermark on your desktop. No, the unsigned driver will not work when you turn it back on.
Sudo isn't an apt comparison as it's not an access rights issue. I think MS considers it a security feature, that they really don't want defeated. It's somewhat understandable as vendors commonly provided unsigned 32 bit drivers, and users would just ignore the big red warning pop ups,
That's not true at all.
Up until last year most of our office pcs were windows 7 64bit on hardware with 2 to 4 gb of ram. About 1/2 were 2 GB. Not great but for the software we ran it was usable.
Sorry, teleporters just kill you and then make a copy. A perfect, soul-less copy.
> In other words: use virtualization without the user knowing or caring that virtualization is even being used.
Yes, but read the use cases people are citing carefully. The typical reason people legitimately cling to 16 bit software is often due to some legacy software that has an unusual dependency on direct communication with hardware. The VM abstraction will likely break things the same way emulation does.
Unless you need the extra memory for Excel there is no benefit to 64bit Office.
Sorry, teleporters just kill you and then make a copy. A perfect, soul-less copy.
I believe Lion was the last version to allow the 32bit kernel.
Sorry, teleporters just kill you and then make a copy. A perfect, soul-less copy.
Windows has granular permissions. Not a primative 1970's all-or-nothing security model.
The CPU still starts up in 8088 8 bit mode. The problem is that MS largely doesn't care about its legacy API.
What a bunch of crap.
The hardware can't do it. End of discussion, liar.
"His name was James Damore."
AMD designed x64 mode to not support 16 bit or "real" mode.
Nope, it's not legacy stuff. It's hardware. Once you enter 64-bit mode on x64, you cannot run real mode or 16 bit applications. VM software is required to emulate this in software, with the hope that what you're emulating will hoist itself into 32 or 64 bit mode so it can transfer the state from the software emulator to the hardware and run on hardware directly. If your application stays in real mode, you're running basically on emulated hardware. Of course, stuff like UEFI is natively 32-bits, so if it can, your VM software will prefer that over legacy.
This was by design by AMD. They wished x64 to get rid of all the legacy stuff. However, unlike Intel ia64 (Itanium), AMD wanted some backwards compatibility - there's a lot of 32-bit software out there so instead of running a 32 bit emulator, it can run on hardware.
The good news is the 16 bit era should soon be fully emulatable in software - stuff like DOSbox should be able to run Windows 3.1 in Enhanced mode fairly swiftly allowing for 16 bit apps to be fully retired.
Windows could emulate 16bit - the software is usually very old, so the performance impact of emulation should not be noticeable.
No idea why, but the 64-bit Hololens runs 32-bit Windows. (Though the ability to run 16-bit applications is probably more important.)
Y2K came wether or not we wanted it to. We survived because we upgraded. We need a 16/32 bit apocalypse to force the same with old software. Fortunately there's no stopping time so we had to do the Y2K thing. But we need to force the end of legacy stuff too. Apple does a better job than MS here. MS seems like they go out of their way to keep old crap running, and they're not helping the security of the planet in doing so.
the glorious opportunity to be embraced by our benevolent Micro$oft on both new and old machines to relentlessly guide us toward the cloud. The CLOUD! The cloud choose who will go and who will stay....(Toy Story). Also, I bet if you did a bit of digging and experimenting, you'd find that 32-bit Window$ 10 has fewer vulnerabilities and runs colder. No, you won't be playing new video games or graphic designing, but they probably serve a lot like what Raspberry Pi users do with their stuff. Simple things without a lot gunk you don't need. 64-bit typically uses more RAM and CPU/GPU, as well as having software larger in size. It's also possible that the government was dumb enough to have contracts with them but too broke to upgrade everything.
Now, no one is going to perform an OS upgrade on an existing MRI of course.
You lack imagination!
Imagine Component A breaks on the system. Now, imagine Component A has been retired for a decade, but you can replace it with Component B. Of course, the drivers for Component B don't work on anything but Windows 7.
Guess what... OS upgrade!
Reading code is like reading the dictionary - you have to read half of it before you can go back and understand it.
That they offer it is no reason others must support it.
It's a little ugly to be bothered at other people's lack of purity on matters like this. Nobody's making him do anything with it. Leave well enough alone.
For every problem, there is at least one solution that is simple, neat, and wrong.
Perhaps it makes sense for Windows to be 64-bit only, but Linux still runs very well on older hardware.
Example: I support Linux laptops for several people, and not one of them has a 64 bit processor. Laptops that would otherwise end up as e-waste but are still very capable of doing everything the users want once you replace the hard disk with an SSD and max out the RAM.
"Nine times out of ten, starting a fire is not the best way to solve the problem." - my wife
'there is zero downside' - Absolutely, completely Wrong
'lower performance' - Wrong (depending on what you're doing)
I'm running 64-bit on my desktops because they've got tons of memory, but...
Besides 32-bit CPUs requiring 32-bit OS (which other people have covered extensively), if you've got a 64-bit CPU but only 512MB or 1GB of memory, like a Beaglebone Black or RasPi3, then running 32-bit OS and apps can save you quite a lot of memory and disk space because more things can be allocated in 4 byte chunks rather than 8 byte chunks.
Let's take a look at the venerable Notepad++, version 7.3.3. The 32-bit exe is 2.32mB and the 64-bit exe is 2.781mB. That's not 'omg', but it's 20% larger and that adds up over all of Windows's exes and anything you install. If I load langs.model.xml (about 281kB) then the 32-bit version uses 13.2MB of memory and the 64-bit version uses 14.7MB of memory, which is 11.4% more. Again, certainly not a doubling, but when you've only got 512MB of RAM this really adds up.
The 'lower performance' thing is hogwash too. If you're doing heavy 64-bit math then the 64-bit app is probably going to win. If you're doing lots of disk reads/writes and string processing the 32-bit app may well win (slightly) just because you're slinging less data around.
I guess I know who not to use for cloud backup.
One: memory. 64 bit applications use more memory.
Two: storage. 32 bit compatibility means 32 bit libs alongside 64 bit
Finally, apart from compatibility, there isn't much upside for 64 bit if you have less than 4GB of ram.
I don't know if Windows does anything with it, and in practice I don't think it's used, but https://en.wikipedia.org/wiki/... is an example of using 32 bit x86 but requiring x86_64 because of memory.
XML is like violence. If it doesn't solve the problem, use more.
*not* MRI, but I have direct experience supporting hugely EOL'd equipment.
There are vendors out there who don't advertise in the normal channels, but their specialty is finding and sourcing that "Component A" you need, generally for an eye watering markup over MSRP, even when accounting for inflation.
I needed some PECs (Pin Electronic Drivers) that simply didn't exist anymore and the Altera FPGAs that drove them in the system too. I didn't have the source for the FPGAs anymore, all I had was a known good dump from one of the units, but that's good enough.
Said company sourced the PECs (in the needed 16 pin PDIP or CERDIP package) at a price of $15 each, the FPGAs about $375 each.
I think the FPGAs were only 200% above retail, but those PECs used to sell for about $0.65 each.
Still, they had the remainder of the world's known supply (about 50K units) and could source them. They *also* were able to continue sourcing ATI All in wonder pros that only worked on Windows 98/98SE... and yes we paid through the nose for those too, since they were the only video card that was supported with the "live video overlay" on the machines.
Those systems lived in an isolated lab, where their network connection was to a dedicated bastion host that ran a current OS and provided server software passthrough etc.
Damn that was a fun lab to be the steward of (not).
whois gawk date unzip strip find touch finger mount join nice man top fsck grep eject more yes exit umount sleep dump
There are several answers. One that I have yet not seen posted is that the low-end Windows machine market is still big - and that low-end often has less than 4GB of RAM. Yes, still in 2017.
2GB of RAM is the bare minimum for 64-bit Windows, and all that I have heard about running that way, is that it is not fun.
It is not just about how native 64-bit apps use more memory but also about larger overhead in the OS itself.
Some slightly better performance for numeric workloads is no benefit if it implies that apps needs to swap more to and from disk.
"We mustn't be caught by surprise by our own advancing technology" -- Aldous Huxley
More than likely the vendor will have retired that model and warranty support will have run out. They'd rather sell you another one than have to continue support on an outdated model. Especially a variation of an outdated model.
These aren't "apps".
These are things like the bespoke industrial-control software running a 50-ton press built in 1943, or an EDM cutter that still thinks it's speaking to an ASR-33 terminal at the other end of its RS-232 cable. These are hardware peripherals that would cost upwards of half a million dollars to replace, where reverse-engineering is nearly as expensive and considerably riskier.
The cost of developing a 16-bit-compatible version of Windows is peanuts next to the cost of upgrading.
"They redundantly repeated themselves over and over again incessantly without end ad infinitum" -- ibid.
I preferred the 32-bit version of Windows 7 in some of my computers for many reasons. For one, I liked some 16-bit Windows apps that don't run on 64-bit OS's. I also had some hardware with drivers only available on 32-bit. When Microsoft pulled the plug on XP, there wasn't much choice.
1) Very small-memory devices. I have a tablet that runs Win10 in 2GB of RAM on an Atom chip. While the Atom theoretically is 64-bit capable, it only supports 2GB of RAM and 32GB of storage. So in order to run within those limitations, the 32-bit version of Windows is required - theoretically, you could boot 64-bit Windows in 2 GB, but it wouldn't be able to actually run anything because it would spend all of its time paging (yes, they gave me a 64-bit Win7 HP at work, and it was unusable until the RAM was upgraded). As a practical matter, with a fairly minimal set of startup items, the minimum memory use (idling) in the tablet is about 0.9 GB; it can run Libreoffice and Firefox at the same time, but FF better have only a few tabs open and the LO document better not be huge to avoid massive slowdown due to paging.
This is not a widely-used hardware configuration, but certainly not unknown. Anybody with 4GB or more of RAM should be running 64-bit Windows. And if I can run 32-bit Win10 on that tablet, you could probably even run it on a P4 or even 486 with 2GB - if anybody wants a modern user interface and all its overhead (I get the impression that the internals are not as modern) on very old hardware.
2) Need to run 16-bit software. This has been mentioned. It's a minimal use case, and in 64-bit Windows is easily handled, for 16-bit applications, by using DOSBox to virtualize the app while still allowing access to the main file system. The only legitimate need for 32-bit Windows to do this is where hardware must be addressed with drivers - an exceedingly small population of users, but probably a vocal one. Note: even 32-bit Windows needs to virtualize 16-bit software; that's what the NTDVM is for.
If you want to see a nice little crash, port the NTDVM from a 32-bit system to a 64-bit system, then attempt to run 16-bit software. Doesn't work. Not a bad crash; it just doesn't work. Works perfectly, though, in 32-bit Windows.
I use DOSBox to run the original DOS version of Railroad Tycoon in 64-bit Windows. Works perfectly. I also have Win 3.1 installed under DOSBox in 64-bit Windows; also works perfectly, and allows use of 16-bit Windows games.
And for those making the comment that you need 32-bit Windows for 32-bit software: NOT. 32-bit software works fine in 64-bit Windows; it and the CPU are designed to do that. Even some parts of the OS distribution are still 32-bit. Check out the details list in Task Manager sometime.
I hope you're being confused by the situation (well I don't wish confusion for you)
As far as I know Debian drops support for older 32bit x86 CPU, but does not drop support for 32bit x86 CPU.
CPU compliant with i486 and i586 will be dropped, while CPU compliant with i686 will work.
This should mean an AMD K6/2 won't run, but a Pentium Pro will run (due to some missing or broken instruction or feature in the K6). An Athlon (original and XP) will run but might be unable to run certain software that requires SSE2, such as Firefox 52 and linux versions of evil software.
AMD Geode won't run, or maybe might, I don't know.
Cyrix won't run.
Pentium, Pentium MMX and 80486 definitely won't run. Although I imagine some people might make an unofficial, unsupported i486 version (no idea how hard it'll be but in the same way you still can find some Ubuntu for PowerPC Macs)
I think that by the way, Pentium Pro or Pentium II 233 machines are more likely to have survived to this day than K6/2 450 and such.
Unless you have uncommon specialty hardware we shouldn't have to fear anything about the old desktops with 512MB and 1GB RAM.
Sci-Fi/Historical viewpoint: the US now is sort of where Europe was before WW2. What industry remains is stuck with legacy equipment and infrastructure. Industry that was highly cost-sensitive long ago move offshore for both lower labor cost AND for the ability to move into new facilities with modern equipment. The US could reclaim some of that industry if it could afford to throw out the old stuff and start over - but it can't afford to do that. So we have a lot of industry that is stuck with old stuff, period, and will be until it goes out of business and is either recycled or is purchased by somebody with the money to rebuild using modern systems. That somebody might not be based in the US.
Health Care is a prime example of that - those gadgets that cost bazillion$ 5-10 years ago are still being paid off/depreciated, so the bean counters won't let them be replaced even if new stuff (unfortunately, gazillion$ instead of bazillion$) works far better. Industrial gear is not one of those places where the price drops every year.
that means we need to quietly, invisibly, continue to support BOTH the 32-bit and the 64-bit versions of every Microsoft OS they release.
No it doesn't. I hate to be made to defend Microsoft here, but this is their/your decision to make here. You could drop 32bit Windows support, but you choose not to.
The 32-bit version of Windows supports 16-bit DOS programs via NTVDM and Windows 3.1 programs via WOW, while the 64-bit version does not.
Siemens MRI systems run on Windows XP 64 bit and the imager actually runs Linux (actually Linux controls a bunch of DSP programmed in multiple full length FPGA array cards).
As far as I'm aware, some GE MRI also run Linux although they used to be a Sun shop (Solaris) and still some older 1.5T systems which they still sell runs on Octanes (SGI).
MRIs were mostly developed through the late 90s through 2000s and the OS choices reflect it, Microsofts offerings weren't nearly stable enough for cutting edge technologies. You basically see a huge gap between DOS and Windows XP SP2 although many DOS systems eventually got converted to have the Windows shell, true 95-ME apps are nearly absent.
Custom electronics and digital signage for your business: www.evcircuits.com
Not necessarily, I still have to keep PPC systems around for some legacy stuff. The nice thing is that Apple has been pushing for developers for cross platform because they tend to switch (from Motorola to IBM to Intel to Intel64 to ARM). Also a lot of it is Unix, cross platform is sort of built into the C/C++ language while Microsoft has always been pushing for its own lock-in so now you have things that are written for 16 bit API which cannot be compiled to a 32 bit API (true for anything that starts with Visual or ends with .NET)
Custom electronics and digital signage for your business: www.evcircuits.com
64-bit Windows requires signed drivers, but (contrary to popular misconception), they don't *have* to be Microsoft-signed WHQL-approved drivers. You can actually generate your own signing key & repackage older drivers for win64... the only catch is that win64 treats drivers signed by an untrusted key the same way win32 treats drivers that aren't signed at all.
In other words, all win64 drivers have to be signed, but some signatures are more equal than others.
You can't do virtual 8086 mode under a "long mode" OS but you can do 16 bit protected mode.
The reason you can't run win16 apps under 64-bit windows is simply because microsoft couldn't be bothered doing the development/debugging work to make wow work on top of wow64. You can run 16 bit windows apps on 32 bit wine on 64-bit linux.
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
MRI is a bit of a stretch, they're not going to run basic Windows if they're smart - although most do have some front end that's a PC/Windows box because managers and executives aren't necessarily smart. But they can be PCs that still ahve 32-bit CPUs. Why not? If it's not broken then don't fix it!
There are some expensive medical equipment makers that do go and stockpile parts so that they can still be used beyond the part's end-of-life. If you use commodity parts in a mission critical system then that's what you need to do. If you want longer and higher quality support then you dump Windows and get Linux.
Look, 32-bit CPUs work! We also have 16 and 8 bit CPUs still in wide use. Founders of cloud startups shouldn't worry about this, they're only selling their product to consumer technophiles anyway.
The machine shop at my job has tons of internal paperwork that gets generated by some custom 16 bit windows apps. They generate dynamic forms based on the options and then print a postscript file. Easier to run them in XP mode in Windows 7 than write something new from scratch.
Only the State obtains its revenue by coercion. - Murray Rothbard
Nothing really wrong with AS/400. Those machines last forever until someone from IBM shows up and shuts them down. The architecture and underlying OS is fascinating. They eliminated problems like buffer overflows using hardware. Now the OS has been ported to the POWER architecture, it's not going away anytime soon.
Only the State obtains its revenue by coercion. - Murray Rothbard
it's all about clicks. people can put total fucking garbage on a blog and /. will link to it and make that guy a ton of money. "processes" ? jesus.
“Common sense is not so common.” — Voltaire
I've been setting up businesses with installs of vDos and it's worked very well for them. Most recently I setup a small practice with vDos so they can continue to run their old software and maintain HIPAA compliance without having to buy all new software and training for their staff. (you typically have to send staff to a seminar to get them set up on the new software). We even got the printers working, which is helpful because one of the features of the old software was the ability to print on carbon copy forms (dot matrix printer). There is carbonless paper for laser printers now, but it's actually kind of a hassle where you have to flip it over before someone can write on it.
“Common sense is not so common.” — Voltaire
Microsoft gives OEMs free, as in beer, or low-cost 32-bit Windows OS licenses for equipment that falls within certain hardware limits (screen size, RAM,etc.), that is why you can find $89 Win10 Tablets, for example.
Ken
Continuing to maintain an entire operating system platform to support software that was written before this year's college grads were even born is just plain insane. That's way too much effort for what should be almost zero benefit.
Ever heard of MVS, VM, VMS, or UNIX? All of them (and many others) were developed 40+ years ago and still support software written 4 decades ago today - and are running in many, many commercial environments on current hardware.
Ken
No really, this question is beyond stupid. It's obviously because someone still needs it for old hardware. They wouldn't bother selling it if nobody was buying.
BeauHD. Worst editor since kdawson.
THIS! Add to that the fact that some business only run 32bit legacy software and running a 64bit OS would do nothing but add overhead.
64-bit has additional security. Some from the 64-bit CPU itself and some from the 64-bit OS implementation.
Microsoft wants everyone to use Windows 10. Including the users of older computers (32bit CPU and/or less than 4GB RAM), so they made a 32bit version ...
No, many "older" computers are unable to run Windows 10 because the NX bit support is not present. Microsoft expects "newer" 32-bit machines.
Some people also use 16 bit apps. Guess what does not run in 64?....
Guess what does run, the virtual machines that runs DOS or OS/2 1.x.
Seriously, if you have some sort of legacy situation that needs a 16-bit app it might be safer to have it in a VM that can be moved from machine to machine, host OS to host OS, etc.
Just another note on EOLed equipment: Intel ONLY stopped producing the i386 in 2007 (nearly 20 years of production for the CPU) because it was that widely used.
This mentions a minimum of 32GB storage for 32-bit and 64GB storage for 64-bit for "Windows 10 Cloud":
https://betanews.com/2017/04/2...
64-bit Windows takes more disk space because of the syswow64 directory etc.
Notice it also mentions 4GB of RAM, which makes me wonder about PAE.
Anything aviation, space and/or military-related also seeks to be as far behind the curve as possible, to maximize "proven reliability". Customers and prime contractors demand (and end up paying for) long product life-cycles from their sub's. Anything COTS (like PC's) is stock-piled at the program's inception, to ensure continued availability of identical parts/components, throughout the projected system life-cycle. Then there's a further scramble to procure (by then EOL'ed) parts, when, decades in, the customer inevitably decides they want to extend the service life, or re-start production of a mature system.
Why do they publish a 64 bit version of office but tell you not to use it ?
See how many people object. If it's a small number then stop supporting it in the next version.
There are still a lot of legacy PLC5 systems in use, and there are even more SLC systems. Lots of those communication drivers only work in 32 bit environments. The panelviews are another story...
You're either fundamentally missing the point or deliberately avoiding it. I can't tell which. All of those things, to the extent that they are still in use, are still in use because they are actively maintained. Nobody in their right minds is running a 40-year-old version of UNIX. They're running a recent build of Linux or OS X or whatever.
And when you say that they still support software written four decades ago, you're grossly overstating things. For example, although ostensibly you could compile and run a properly written 40-year-old piece of UNIX software today, you would at an absolute minimum have to recompiling it, because A. modern UNIX systems don't even run on the same CPUs as UNIX systems from 40 years ago, and B. even if they did, modern UNIX systems don't even have the same set of system calls under the hood; they use 64-bit system calls with 64-bit inodes, 64-bit size_t and off_t, yada, yada, yada.
And the reality is that the vast majority of software from forty years ago won't even compile because of backwards-incompatible changes in header file names, compiler behavior, etc. You end up making at least minor changes before you can even start running it.
Being able to tweak, compile, and run 25-year-old source code is fundamentally different from being able to run a 25-year-old binary unmodified. Nobody in their right minds should be doing the latter, because supporting such a model basically requires that all OS improvements grind to a halt.
Check out my sci-fi/humor trilogy at PatriotsBooks.
You can run 16-bit applications natively on 32-bit, but not on 64-bit.
Any sufficiently advanced technology is indistinguishable from magic.
There are 32-bit ASR-33 terminal emulators available out there. And if they're still running ancient systems for controlling their PLCs, they're running on borrowed time before malware takes over those systems and causes millions of dollars in damage or worse (e.g. StuxNet). Legacy systems written decades ago simply are not designed for the world we live in today, and it is fundamentally unsafe to continue using software written so far back, period. We're at least a decade past the point where the risk of not upgrading that sort of software exceeded the risk of replacing the software, and anybody who says otherwise hasn't fully thought through the risks.
Besides, a properly executed transition is amazingly safe. I've had conversations with a former coworker whose father was doing exactly that about five years ago. Basically, you start out by running the old and new systems in parallel, with the new software in a report-only mode. Then you compare the data reported from both systems and compare what actions would have been performed in response to the signals from the newer system, and you flag any places where those decisions differ. Then you analyze those differences and fix the software. Eventually, after running for some reasonable number of weeks/months/years with no observed differences, you conclude that the old software is not necessary, you switch to allow the new software to control things, and then you tear down the old software so that its security issues can cause no further harm. It's just like any other deployment of updated programming for one of those pieces of equipment, only on a bigger scale, involving bigger changes, and probably some new hardware....
The bigger the risk, the longer it takes, obviously, but twenty-two years is an eternity.
I guarantee those presses and cutters have had mechanical maintenance over the years to keep them running, replacing parts, etc. Why should it still be running software that hasn't been touched in decades?
As for reverse engineering being expensive, that mistakenly assumes that each of these pieces of software is being used by exactly one company. If that were the case, they would have the source code, and they could upgrade it. If they don't, that means that they bought the software, and so did hundreds of other companies around the world. If it costs half a million dollars to reverse engineer the software and there are 500 companies, then we're talking about less money per company than the cost of buying a new machine to run the upgraded software on.
Yes, yes, there's still the issue of things like PLCs where you have the software that runs on them but not a 32-bit version of the software that uploads programming to them, and in those cases, it is a pain in the backside to replace the PLCs with new ones using the process I described above, but in the end, it is worth it to not be running ancient cruftware that could break at any minute.
More significantly, at some point in the not-too-distant future, I fully expect Intel to decide that emulating the 16-bit and 32-bit i386 ISA is a waste of copious amounts of valuable die space, and just cut out that feature entirely as part of a die shrink. And I would not be even slightly surprised if Apple's planned elimination of 32-bit support in OS X is in preparation for just such an optimization. If and when Intel does drop legacy mode, anybody still using 16-bit code will suddenly be racing against the clock to replace it before they find themselves unable to get replacement hardware should anything break. That's not a position that anyone should want to be in. Better to start planning for a replacement sooner when you can do so on your own terms.
Check out my sci-fi/humor trilogy at PatriotsBooks.
No, the solution is to upgrade your PLCs and other hardware to more modern replacements that can be controlled by a modern computer. That doesn't mean replacing the industrial equipment, just its interface to the outside world.
CNC? Really? That's just about the most trivial thing you could pick. For many CNC needs, you could buy off-the-shelf control boards, plug them into a modern computer running a modern OS and modern CAD software, do some configuration, and you're done. The hard part is going to be updating the file format to be compatible, and that's still likely to be trivial.
No, it starts getting fun when you're talking about hundreds or even thousands of sensors and valves in a chemical plant that covers thousands of acres, all of which talks using an ancient protocol to software that only runs on 16-bit DOS. That's when it gets fun, because you actually have to write custom software for all of those sensors and valve controllers, on top of new enough hardware that you can usefully talk to it using a modern OS. And then you have to deploy the new setup in such a way that both old and new systems can run in parallel (ideally in lockstep) so that you can then verify that the new setup behaves identically to the old one over an extended period of time before disabling the old setup and letting the new one start running the show, so to speak. But even in that extreme example, you're still just replacing the PLCs, not the whole chemical plant.
The industrial equipment, realistically speaking, should run itself using PLCs or other hard-realtime systems. The Windows box typically is just a way of updating the software and/or sending new sets of instructions to it. So even if Windows 10 sucks at realtime (which it probably does), that's mostly moot, because it would typically be used as a glorified field programmer, not as an industrial system per se. At least one would hope....
Check out my sci-fi/humor trilogy at PatriotsBooks.
just like your software supports 32 so you can run on 32 windows, so does windows support 32 so it can run 32 something else. I'd have thought that you could see your compatibility goals in the next cascade.
all it takes is one special device, that works perfectly save for a huge architecture shift. not every application needs more security, and more performance. Some are just perfect as-is, and simply need an OS that's readily available.
Think about something as simple as banking software. We know that most are still age-old DOS. Imagine one that was "upgraded" to XP ten years ago. It's been fine. It's already leaps and bounds above all of the other banks. No one wants to rebuild it now.
It doesn't need more performance, it's working fine. It doesn't need more security, it's just a bunch of in-house banking tools like mortgage calculators. But you want them to rebuild it for 64bit only because they might have a compatibility issue and don't want to retest the whole entire thing to figure out where?
One reason that 32 bit Windows may still exist is that it offers support of old 16 bit Windows programs. 64 bit Windows does not.
32 bit Windows also uses a bit less memory. That was a big deal for those 1GB systems that were offered through the first release of Windows 10 (the Anniversary Update changed the minimum RAM requirement to 2GB, a long overdue move) and still helps a bit on 2GB systems. Once you go to 4GB you definitely want to go to 64 bits because 32 bit Windows doesn't support all of your memory.
When was the last time you went to Radioshack (ha!) and bought a bunch of VACUUM TUBES to fix your multi-million dollar airplane. Well, the military has that exact problem.
I doubt that. The B-52s were all upgraded long ago; it's not as if the ones being flown today are the exact same aircraft as the ones in 1955. There are almost certainly no vacuum tubes in them.
There definitely are problems with parts acquisitions for old fleets though. I've heard stories of personnel tasked to monitor ebay in the hope of snatching up any parts that get listed.
Not all manufacturers provide 64-bit drivers, especially for older hardware. So upgrading to a 64-bit OS could require buying a new printer, or scanner, or webcam, etc., something people have no interest in doing, especially if the 32-bit OS they have is working fine. If it ain't broke, don't fix it.
When you have a low power embedded device with just 16 or 32 GB of storage, the difference in size of a 32 bit Windows installation and a 64 bit Windows installation becomes important.
So, yeah, a 32 bit version of Windows on a laptop or desktop system doesn't makes much sense. When you start thinking about things like POS systems and interactive signage systems, the story is different.
Windows XP has about the same market share as all of OSX. The question is why wouldn't they offer it, since it equals their nearest rival in its entirety? If you can be the distant second place runner with your old OS that supports legacy hardware, why not?
Browsing at +1 - no ACs, I ignore their posts. So refreshing!
I never had the chance to directly use one - though I suspect I've interacted with more than one indirectly. My background is related to computers inasmuch as I needed them to more readily accomplish tasks. I actually used to hate computers, for the most part. I've programmed - but I am not a programmer.
But, at the end of the day, even *I* know of the AS/400. I'd consider that fairly basic knowledge for anyone who visits this site. I'd like to hope that everyone here has a basic knowledge of things like UNIX, C, and (probably) at least the TRS-80. They probably shouldn't have to Google FORTRAN, COBOL, or PHP. They should probably not have to Google for things like CPU, RAM, L2 cache. They probably shouldn't have to Google for Gates, Jobs, Stallman, or Torvalds. They should probably also be familiar with the Standard Model, at least algebra, and have a passing familiarity with particle physics and astrophysics. They should probably understand DNA a bit, understand evolution, and maybe even understand a bit about genetic mutations.
The list goes on. Though, I'd add that I guess they don't *need* to know those things - but they should have a willingness to learn. Ideally, they'd already know stuff like the AS/400 and why it's important.
It does make me curious... I bet we could come up with a list of things people should know, prior to posting on Slashdot. Not that they have to know them intimately, but enough to say, "We can use acronyms without confusion and are knowledgeable enough to accurately opine and speculate."
"So long and thanks for all the fish."
You can call it an eye-watering markup, or you can call it a fairly modest fee for twenty years' rent on storage space, plus the testing to make sure it still works as advertised...
life always has been and always will be a money issue. no money. no life.
Yes, thank you for restating what I just said.
I browse on +1 so AC's need not respond, I won't see it.
Essentially the 64 Bit versions cannot be used in many instances as:
1. 16 Bit software won't run any more
2. Drivers need signatures
Most Windows software obviously still is 32 Bit as it's distributed as binaries. If you ship 64 Bit software you unnecessarily limit your market. Few applications need the advantages of 64 Bit as development started when 16 Megabytes was a lot of RAM.
Pretty much. If they have the source code for a 16-bit DOS or Windows app, porting it to 32-bit Window is mostly trivial. It's more than a recompile, but unless it was written in 8086 assembly language, it is obviously much, much easier than reverse engineering it. With that said, given the age of the code in question, it would probably make more sense to keep the interesting core bits that talk to hardware and wrap it with a current, modern UI using modern APIs.
What makes lots of industrial stuff particularly problematic is that even if you have the source code for your bits, it often uses some closed-source compiler/uploader toolchain that only runs on ancient hardware/OSes. In an ideal world, obtaining copyright or patent protection would require making the source code available either publicly or in escrow so that when the company goes away, people who own hardware that depends on it can maintain it themselves, but I digress.
Check out my sci-fi/humor trilogy at PatriotsBooks.
I personally oversee a couple of ancient computers running a sewer plant with 32-bit Windows 7 that are locked down and completely stable. No calling home, private plant Ethernet and manual updates. In fact, while passing by a dumpster I was overjoyed to rescue an 8-year-old computer that had been CHUCKED by a fellow employee, and reconditioned it as another standby. Fortunately it wasn't hard to convince my (excellent) boss that of all the procurement choices --- and she was ready to spend some bucks --- that rejected computer (with a SATA Barracuda no less!) actually represented our best possible pick or the moment.
There are many platforms out there who would benefit to Just Say No to variable speed fans, 'green' features cycling disks on and off, CPUs and motherboards clocked beyond the mission so gamers can drive gigapixel displays and watch triple-HD television, OS choices that place you squarely into a world of someone else's evolving shit that becomes your shit when a creepy new feature gets away from Dr. Frankenstein.
These are appliances, not firewall-exposed Internet whipping posts bound to the lowest common denominator of corporate tactical desire and predatory engineering that always seems to trade for lifespan. Because Pepperidge Farm Remembers.
<blink>down the rabbit hole</blink>
Intel's mania for market segmentation means that 32 bit only x86 processors are still manufactured and sold. And Microsoft's mania for market segmentation means systems intended to operate Windows are still sold with less than 4 megabytes of memory making a 64 bit operating system less useful; not supporting more then 2 gigabytes of physical memory through PAE did not help with this.
As someone who is supporting a legacy environment (six-year-old software from a company since absorbed by a larger one, with a mixture of other outdated software and Office fucking 2003) that is being punted this year, I often wonder about that statement. It may be that the software (or hardware) a company uses follows a process that they set up surrounding the software and when it works, it works well enough, but my personal experience has been that when it doesn't work it's a nightmare.
As an example, I spent 13 hours this past Friday recreating transactions in a secondary system because, for reasons I cannot determine, it decided to stop the normal auto-logging of transactions. The only way to "properly" enter records into this system is to re-do the entire process.
I was an intern at a large shipping company, and they were still using a 1992 DOS program to manage certain portions of shipments. While it worked, it took an entire department to manage and was incredibly manual and time-consuming. The company had mandated all DOS programs go away, but didn't want to actually provide support for transitioning the process, so the project got handed to a poor intern (me). I was the sixth person to attempt replacing it (all other attempts being by other interns), and because the department was so entrenched with the program my attempt went no where, too.
The transition and learning curve might not be easy (or cheap!) but I think a lot of places that hang onto systems with the claim that "they still work" would find that they really didn't work once they have gone through an overhaul.
And that's where you part company from industrial reality. A significant part of the high maintenance costs of industrial equipment (not the disposable crap that is sold to street consumers, with it's 20-year lifespan) is the maintenance of those stores of old equipment. P>I bet that you think that WD-40 is for loosening tight nuts, not for mothballing electronics. You probably don't even know what "mothballing" is, except as a particularly niche application of Rule 34.
Birds are not dinosaur descendants;birds are dinosaurs, for all useful meanings of "birds", "are" and "dinosaurs"
WINE supports running 16-bit Windows apps on 64-bit Linux
Custom electronics and digital signage for your business: www.evcircuits.com
WINE supports running 16-bit Windows apps on 64-bit Linux. The limitation is in the Windows OS because they chose to remove the necessary code so you'd buy into their virtualization platform.
Custom electronics and digital signage for your business: www.evcircuits.com
Have to agree with you on your first point. The biggie I see all the time here is the "Java? Does anyone still use that? *snort* something something applets."
Literally one of the biggest platforms out there, and people here think it's obscure.
You are not alone. This is not normal. None of this is normal.
Yes on the first part, not so much on the second.
They had a 15 day window to notify if not to spec...
if you didn't test it that's on you.
whois gawk date unzip strip find touch finger mount join nice man top fsck grep eject more yes exit umount sleep dump
It is pretty simple, that is the primary reason why. I have to support one legacy application that only runs on 32bit machines, and that we can't reasonably update to work on a 64bit machine. I know of a handful of other legacy application in our organization in the same boat. We figure we have until 2020 to design and replace said applications (as corporately we only support Windows 10 64bit, and Windows 7 32/64bit). It is quite irritating really. Anyway at one point we did a bit of analysis and found it was basically *a lot* cheaper at least in the short term to simply buy users 32bit machines to use than it was to design and replace systems right away. We know it is only a temporary fix, but it gives us the time to replace the legacy apps. I'm sure there are other reasons like hardware, but given how long 64bit cpus have been around and ubik I doubt anything but really ancient machines are limited by this so it is probably a pretty minor issue. It is all about all those legacy apps hanging around that just haven't been replaced yet.