11 ms·

I've just checked which 32-bit apps I have (system information/software/applications if you wonder) and turns out if I upgrade I lose: - My scanner support (th

by smsm42 7y ago

I've just checked which 32-bit apps I have (system information/software/applications if you wonder) and turns out if I upgrade I lose: - My scanner support (they have new version, which is insanely buggy and can't even detect my scanner properly) - All my games (literally every single one of them turns out to be 32-bit) - I don't play that much but still, would be a shame to lose all of them - Postal label printing app (no idea if they have an update, need to check) - App supporting my stand-alone disk array (not using it too much though) - My niche learning apps (pretty old, from small providers, not sure if they'd ever be updated) Much more than I expected, given that I don't have any exotic stuff like music instruments, specialized equipment, etc. So I personally probably would hold off upgrading as long as I can.

guidedlight 7y ago
It really demonstrates how incredible Windows 10’s 16-bit application support is. Although I understand the Windows codebase is a nightmare.
- ljm 7y ago
  And how much they tolerate it, as it's so embedded in their engineering culture and I imagine "backwards compatibility" is drilled into your face when you start working on Windows at MS. It's not easy to get into the mindset of fixing every problem a 3rd party app creates. Some will say Apple is offloading tech-debt onto client apps, but Microsoft is allowing client appts to offload tech-debt onto itself, and it's big enough to take that burden on so its users can still use the stuff they bought. I dunno, sometimes I hate having to do it but it's all about user/dev experience and if you're optimising for your own employees you're making it worse for everyone else who makes your OS/machinery worth buying. There's got to be some compromise, coz it sounds like if you buy into Apple then you're SOL if they can't be bothered supporting your hardware. Which, additionally, must contradict their environmental aims. It's not good for the environment if upgrading an OS means you throw away your printers and scanners and buy compatible ones.
  - userbinator 7y ago
    As a developer who strongly advocates for and strives to maintain backwards compatibility whenever possible (and even when it isn't so easy...), I can say that it's unfortunately something the vast majority of (younger) developers today don't even think about, much less care for. Perhaps they just haven't experienced stability nor noticed it enough in their daily lives, because all they seem to care about is "new and shiny" and rewriting things constantly. I have written various (Windows) utilities over the years, and some are over 20 years old now and I use them every day. They worked on Win95, they still work through to Win10. They're all tiny single binaries that require no installation, start immediately, and are extremely responsive and low on memory usage. Ironically, it's almost impossible to do that with a "modern" toolchain now, and I'm not even sure if something like that would've ever been possible with the Mac. To me, the idea that backwards compatibility is a "burden" is absurd. Constant churn is a burden. If I had to go and "fix" all my utilities every few years because a new OS broke something that was working before, I would have less time for actual new developments. Instead I can continue to use them and write other things as the needs arise, instead of wasting the effort redoing things that should've still been working. Just "leaving well enough alone" is a big part of it.
    - wtallis 7y ago
      The kind of simple utilities you are talking about would have also been pretty easy to maintain/port from OPENSTEP in 1996 through to current MacOS. Apple's offered pretty good source-level compatibility for the basic stuff, and an easy migration path for tooling. Recompiling something every few years isn't a "constant churn" sort of burden.
      - ericd 7y ago
        There's a lot of stuff out there that's not maintained, but is still useful. So "recompiling every few years" is a pretty big burden.
        sbuk 7y ago
        > There's a lot of stuff out there that's not maintained, but is still useful. I can't see how this is Apple's problem. Holding up development of a platform and technical progression generally for unmaintaned software is not a good working model for anyone, no matter how useful it is. > So "recompiling every few years" is a pretty big burden. As is "supporting everything ever implemented in perpituity"...
- kevingadd 7y ago
  fwiw, upgrading to x64 windows killed 16-bit support, I think? But as far as I know that was due to architectural limitations as much as it was an intentional choice. It's still impressive that 16-bit stuff kept working on x86 windows basically forever.
  - simcop2387 7y ago
    Yea it's not possible (in a way that works without breaking stuff) to drop from 64bit to 16bit the way you can with 32 to 16. That's just a limitation of the cpu architecture that's just not something you can work around. Dosbox and virtualization however do allow that to still be run if you provide the OS bits (install windows 95 or 3.1 in them), so there's still paths forward that will usually work. If they need to talk to esoteric hardware then you might be out of luck still but it might not be impossible to get that to pass through depending on what it is.
    - userbinator 7y ago
      As with a lot of other things, the truth is a bit more subtle than "it's impossible" and closer to "we didn't care enough to try hard enough to make it work": https://www.dkia.at/en/node/180 https://www.dkia.at/en/node/180 http://v86-64.sourceforge.net/ http://v86-64.sourceforge.net/
      - amluto 7y ago
        If that v86_64 thing works the way I think it does, it is not really an acceptable way to do this. If you drop the CPU down from long mode to legacy mode and get an NMI, either you are toast or you have some extremely complicated awful code to handle it. Not to mention that the CPU can’t even address all of physical memory when you do this. Just don’t go there. Use an emulator for DOS code and use the normal kernel support (modify_ldt()) for 16-bit protected mode.
    - amluto 7y ago
      > Yea it's not possible (in a way that works without breaking stuff) to drop from 64bit to 16bit the way you can with 32 to 16. Yes, it is. It’s almost exactly the same. What you can’t do is run v8086 code on a 64-bit kernel without using a VM, most of the code people care about is 16-bit protected mode code. I maintain the messy but small amount of Linux kernel code that makes this work. It is, indeed, gross, because the x86 architecture is awful. But it works fine in practice and there is quite a good test suite these days to exercise the ugly bits in the kernel tree.
- H1Supreme 7y ago
  This is only on 32-bit versions of Windows 10. Which I can only imagine is a very small portion of W10 installs.
karmelapple 7y ago
I’ve also been wondering about Dymo label printers. I haven’t seen anything when I searched - if anyone knows, I’d like to learn!
- wingworks 7y ago
  Maybe not much help to you, but my Rollo Thermal Label Printer works fine on Catalina. Didn't need to update any drivers, it just works as it did before the update.
musicale 7y ago
Apple's backward compatibility is poor, and particularly bad for games. The 32-bit apocalypse kills off a large subset of the Mac's already less-than-stellar game library; and on iOS it already broke many apps that I used, many of which will not be updated. To me it seems like Apple is going in the wrong direction - really I want them to add an x32 ABI to save pointer space for apps that don't need more than 4GB! Stick with Windows/Steam/Consoles/etc. if you don't want a bunch of your games that you purchased to become unplayable every year (unless you add multi-boot to run the old, compatible OS, or run them in a VM, which usually works poorly.) As I have mentioned before, it's a very annoying example of Apple shifting technical debt and maintenance work away from themselves and onto developers, and the overall maintenance burden is greatly increased. I like how the platform moves forward, but I really wish that there were a way of getting desirable security patches and feature improvements in the OS without breaking all of my apps.
- qwerty456127 7y ago
  Does this mean I won't be able to play 32-bit Windows games with CrossOver?
  - zamalek 7y ago
    It depends. * 64bit processes usually can't load 32bit modules, only a 64bit OS can (true for Linux and Windows, I'm not sure if it's true for x86 overall). There's a pretty good chance that only a 32bit CrossOver could load 32bit modules. * Has 32bit support been stripped from the kernel, or has it only been stripped from the installed dynamic libraries? I'd wager that it's stripped from, or partially stripped from, the kernel. Even if Catalina allows 64bit processes to load 32bit modules, the kernel would have to support it. There's a one in four chance your scenario is supported. CrossOver definitely couldn't magically voodoo a 32bit module into a 64bit one, as it's impossible to determine if a register/address is a 32bit integer or pointer; if it doesn't work today, it will probably never work. I'm not sure if macOS supports IOMMU, but an external GPU with a VM might be your saving grace here.
    - duskwuff 7y ago
toufka 7y ago
Quinn is 32bit! Oh no! Best macOS Tetris-like game around.
jedisct1 7y ago
Same here. My Canon scanner is not going to work any longer. And Canon is notoriously bad at updating their drivers, so my scanner will now be a brick.
- serpix 7y ago
  VueScan to the rescue, it supports scanners from the 90s and is also a very good scanning app to boot.
  - LeonM 7y ago
    VueScan works, but it is stupidly bloated compared to the macos native scan tool. I remember how it was so easy to scan directly to multi-page PDF with my Brother portable scanner. The Apple build in capture software was just so easy and clean to use. Then Apple removed TWAIN support in snow leopard, and suddenly my 2 month old 400 euro scanner was no longer usable. :(
spitfire 7y ago
Have a look at vuescan. It's 64bit clean and supports scanners back to the late 1990's. I use it myself and ignore the manufacturers software altogether. Which form my scanner only supported PowerPC. https://www.hamrick.com/vuescan/supported-scanners.html https://www.hamrick.com/vuescan/supported-scanners.html
- Aloha 7y ago
  Vuescan is great, its better than most scanner apps too, insomuch as, its actually good at scanning.
  - Twirrim 7y ago
    > its actually good at scanning Careful now. Scanner manufacturers would have you believe that's nearly impossible unless you remember to make the appropriate sacrifices under a full moon on a marble altar.
- Operyl 7y ago
  I found this application the other day, and despite its look, it really is great.
- appleiigs 7y ago
  Wow, VueScan! A blast from the past. I used it 15 years ago. Glad to see it's still around, maintained by the one guy (and now him and his son according to the website). I'm definitely going to buy a license now ($99) and ditch the 32-bit manufacturer's software. Software like VueScan and USB Overdrive (just bought a license for that too $20) deserve to be in some sort of Apple Hall of Fame.
- js2 7y ago
  I switched to ExactScan to support my Fujitsu S1500M: https://www.exactscan.com https://www.exactscan.com
deleted 7y ago
[deleted]

by smsm42 7y ago

guidedlight 7y ago

It really demonstrates how incredible Windows 10’s 16-bit application support is. Although I understand the Windows codebase is a nightmare.

ljm 7y ago
And how much they tolerate it, as it's so embedded in their engineering culture and I imagine "backwards compatibility" is drilled into your face when you start working on Windows at MS. It's not easy to get into the mindset of fixing every problem a 3rd party app creates. Some will say Apple is offloading tech-debt onto client apps, but Microsoft is allowing client appts to offload tech-debt onto itself, and it's big enough to take that burden on so its users can still use the stuff they bought. I dunno, sometimes I hate having to do it but it's all about user/dev experience and if you're optimising for your own employees you're making it worse for everyone else who makes your OS/machinery worth buying. There's got to be some compromise, coz it sounds like if you buy into Apple then you're SOL if they can't be bothered supporting your hardware. Which, additionally, must contradict their environmental aims. It's not good for the environment if upgrading an OS means you throw away your printers and scanners and buy compatible ones.
- userbinator 7y ago
  As a developer who strongly advocates for and strives to maintain backwards compatibility whenever possible (and even when it isn't so easy...), I can say that it's unfortunately something the vast majority of (younger) developers today don't even think about, much less care for. Perhaps they just haven't experienced stability nor noticed it enough in their daily lives, because all they seem to care about is "new and shiny" and rewriting things constantly. I have written various (Windows) utilities over the years, and some are over 20 years old now and I use them every day. They worked on Win95, they still work through to Win10. They're all tiny single binaries that require no installation, start immediately, and are extremely responsive and low on memory usage. Ironically, it's almost impossible to do that with a "modern" toolchain now, and I'm not even sure if something like that would've ever been possible with the Mac. To me, the idea that backwards compatibility is a "burden" is absurd. Constant churn is a burden. If I had to go and "fix" all my utilities every few years because a new OS broke something that was working before, I would have less time for actual new developments. Instead I can continue to use them and write other things as the needs arise, instead of wasting the effort redoing things that should've still been working. Just "leaving well enough alone" is a big part of it.
  - wtallis 7y ago
    The kind of simple utilities you are talking about would have also been pretty easy to maintain/port from OPENSTEP in 1996 through to current MacOS. Apple's offered pretty good source-level compatibility for the basic stuff, and an easy migration path for tooling. Recompiling something every few years isn't a "constant churn" sort of burden.
    - ericd 7y ago
      There's a lot of stuff out there that's not maintained, but is still useful. So "recompiling every few years" is a pretty big burden.
      - sbuk 7y ago
        > There's a lot of stuff out there that's not maintained, but is still useful. I can't see how this is Apple's problem. Holding up development of a platform and technical progression generally for unmaintaned software is not a good working model for anyone, no matter how useful it is. > So "recompiling every few years" is a pretty big burden. As is "supporting everything ever implemented in perpituity"...
kevingadd 7y ago
fwiw, upgrading to x64 windows killed 16-bit support, I think? But as far as I know that was due to architectural limitations as much as it was an intentional choice. It's still impressive that 16-bit stuff kept working on x86 windows basically forever.
- simcop2387 7y ago
  Yea it's not possible (in a way that works without breaking stuff) to drop from 64bit to 16bit the way you can with 32 to 16. That's just a limitation of the cpu architecture that's just not something you can work around. Dosbox and virtualization however do allow that to still be run if you provide the OS bits (install windows 95 or 3.1 in them), so there's still paths forward that will usually work. If they need to talk to esoteric hardware then you might be out of luck still but it might not be impossible to get that to pass through depending on what it is.
  - userbinator 7y ago
    As with a lot of other things, the truth is a bit more subtle than "it's impossible" and closer to "we didn't care enough to try hard enough to make it work": https://www.dkia.at/en/node/180 https://www.dkia.at/en/node/180 http://v86-64.sourceforge.net/ http://v86-64.sourceforge.net/
    - amluto 7y ago
      If that v86_64 thing works the way I think it does, it is not really an acceptable way to do this. If you drop the CPU down from long mode to legacy mode and get an NMI, either you are toast or you have some extremely complicated awful code to handle it. Not to mention that the CPU can’t even address all of physical memory when you do this. Just don’t go there. Use an emulator for DOS code and use the normal kernel support (modify_ldt()) for 16-bit protected mode.
  - amluto 7y ago
    > Yea it's not possible (in a way that works without breaking stuff) to drop from 64bit to 16bit the way you can with 32 to 16. Yes, it is. It’s almost exactly the same. What you can’t do is run v8086 code on a 64-bit kernel without using a VM, most of the code people care about is 16-bit protected mode code. I maintain the messy but small amount of Linux kernel code that makes this work. It is, indeed, gross, because the x86 architecture is awful. But it works fine in practice and there is quite a good test suite these days to exercise the ugly bits in the kernel tree.
H1Supreme 7y ago
This is only on 32-bit versions of Windows 10. Which I can only imagine is a very small portion of W10 installs.

karmelapple 7y ago

I’ve also been wondering about Dymo label printers. I haven’t seen anything when I searched - if anyone knows, I’d like to learn!

wingworks 7y ago
Maybe not much help to you, but my Rollo Thermal Label Printer works fine on Catalina. Didn't need to update any drivers, it just works as it did before the update.

musicale 7y ago

Apple's backward compatibility is poor, and particularly bad for games. The 32-bit apocalypse kills off a large subset of the Mac's already less-than-stellar game library; and on iOS it already broke many apps that I used, many of which will not be updated. To me it seems like Apple is going in the wrong direction - really I want them to add an x32 ABI to save pointer space for apps that don't need more than 4GB! Stick with Windows/Steam/Consoles/etc. if you don't want a bunch of your games that you purchased to become unplayable every year (unless you add multi-boot to run the old, compatible OS, or run them in a VM, which usually works poorly.) As I have mentioned before, it's a very annoying example of Apple shifting technical debt and maintenance work away from themselves and onto developers, and the overall maintenance burden is greatly increased. I like how the platform moves forward, but I really wish that there were a way of getting desirable security patches and feature improvements in the OS without breaking all of my apps.

qwerty456127 7y ago
Does this mean I won't be able to play 32-bit Windows games with CrossOver?
- zamalek 7y ago
  It depends. * 64bit processes usually can't load 32bit modules, only a 64bit OS can (true for Linux and Windows, I'm not sure if it's true for x86 overall). There's a pretty good chance that only a 32bit CrossOver could load 32bit modules. * Has 32bit support been stripped from the kernel, or has it only been stripped from the installed dynamic libraries? I'd wager that it's stripped from, or partially stripped from, the kernel. Even if Catalina allows 64bit processes to load 32bit modules, the kernel would have to support it. There's a one in four chance your scenario is supported. CrossOver definitely couldn't magically voodoo a 32bit module into a 64bit one, as it's impossible to determine if a register/address is a 32bit integer or pointer; if it doesn't work today, it will probably never work. I'm not sure if macOS supports IOMMU, but an external GPU with a VM might be your saving grace here.
  - duskwuff 7y ago

toufka 7y ago

Quinn is 32bit! Oh no! Best macOS Tetris-like game around.

jedisct1 7y ago

Same here. My Canon scanner is not going to work any longer. And Canon is notoriously bad at updating their drivers, so my scanner will now be a brick.

serpix 7y ago
VueScan to the rescue, it supports scanners from the 90s and is also a very good scanning app to boot.
- LeonM 7y ago
  VueScan works, but it is stupidly bloated compared to the macos native scan tool. I remember how it was so easy to scan directly to multi-page PDF with my Brother portable scanner. The Apple build in capture software was just so easy and clean to use. Then Apple removed TWAIN support in snow leopard, and suddenly my 2 month old 400 euro scanner was no longer usable. :(

spitfire 7y ago

Have a look at vuescan. It's 64bit clean and supports scanners back to the late 1990's. I use it myself and ignore the manufacturers software altogether. Which form my scanner only supported PowerPC. https://www.hamrick.com/vuescan/supported-scanners.html https://www.hamrick.com/vuescan/supported-scanners.html

Aloha 7y ago
Vuescan is great, its better than most scanner apps too, insomuch as, its actually good at scanning.
- Twirrim 7y ago
  > its actually good at scanning Careful now. Scanner manufacturers would have you believe that's nearly impossible unless you remember to make the appropriate sacrifices under a full moon on a marble altar.
Operyl 7y ago
I found this application the other day, and despite its look, it really is great.
appleiigs 7y ago
Wow, VueScan! A blast from the past. I used it 15 years ago. Glad to see it's still around, maintained by the one guy (and now him and his son according to the website). I'm definitely going to buy a license now ($99) and ditch the 32-bit manufacturer's software. Software like VueScan and USB Overdrive (just bought a license for that too $20) deserve to be in some sort of Apple Hall of Fame.
js2 7y ago
I switched to ExactScan to support my Fujitsu S1500M: https://www.exactscan.com https://www.exactscan.com

deleted 7y ago

[deleted]