flat assembler
Message board for the users of flat assembler.
 Home   FAQ   Search   Register 
 Profile   Log in to check your private messages   Log in 
flat assembler > Heap > Apple prepares macOS to drop 32-bit app support

Goto page 1, 2  Next

Should 32-bit support be dropped by all major OSes?
No, I still run DOS apps!
33%
 33%  [ 2 ]
No, I still run Win32 apps!
33%
 33%  [ 2 ]
Yes because I hate everything! Die, legacy, die!
33%
 33%  [ 2 ]
It's all Donald Trump's fault! Everything's his fault!
0%
 0%  [ 0 ]
I prefer non-x86 cpus (e.g. ARM) anyways, so I don't care.
0%
 0%  [ 0 ]
Apple always knows what's best for us. Resistance is futile!
0%
 0%  [ 0 ]
As long as Netflix, Spotify, Minecraft still work, I don't care.
0%
 0%  [ 0 ]
Total Votes : 6

Author
Thread Post new topic Reply to topic
rugxulo



Joined: 09 Aug 2005
Posts: 2279
Location: Usono (aka, USA)

Apple prepares macOS to drop 32-bit app support

Apple prepares macOS for discontinuation of 32-bit app support


OS News wrote:

When users attempt to launch a 32-bit app in 10.13.4, it will still launch, but it will do so with a warning message notifying the user that the app will eventually not be compatible with the operating system unless it is updated. This follows the same approach that Apple took with iOS, which completed its sunset of 32-bit app support with iOS 11 last fall.

Post 09 Feb 2018, 21:49
View user's profile Send private message Visit poster's website Reply with quote
yeohhs



Joined: 19 Jan 2004
Posts: 168
Location: N 5.43564° E 100.3091°

Very Happy Die legacy! Die!

_________________
“It’s not that we have a short time to live, but that we waste a lot of it.”
-Lucius Annaeus Seneca
Post 09 Feb 2018, 22:29
View user's profile Send private message Visit poster's website Reply with quote
Furs



Joined: 04 Mar 2016
Posts: 1155

Well, it's Crapple, their entire platforms are one clusterfuck of volatility, I'm seriously sick of seeing devs complain about what newer Mac broke their code and they need to rewrite, wasting their time from Windows ports of their software (i.e. they slow down releases which pisses me off, because of a pathetic volatile platform that requires their attention non stop just to keep it "alive"). I wish they'd just stop writing Mac software to teach Crapple a hard lesson.

That said, I am indeed worried a bit here, because of Wine. CrossOver (the "commercial" Wine) gets most of its profit off Mac users. Obviously, people use Wine to run Windows applications on Mac or Linux. Especially older games, since Mac is so piss poor for native gaming, and they work excellent under Wine (sometimes even better than on Windows, especially really old games, 3D games are the same though).

If those stop working (because of Crapple) because Wine/CrossOver stops working, they might switch to Windows which results in less profit for CrossOver (I mean, most people use Mac because "it just works" and other bullshit, so unlikely they will switch to Linux, power Mac users are very few).

That's bad, since it eventually means less backing for Wine, which affects me. Other than that, I couldn't care less about Mac and if it weren't for that I'd love to see it crash and burn.

There's nothing wrong with, for example, older software or games, just like there's nothing wrong with older movies (even if graphically they're a bit worse). I mean, most software or games don't receive updates because they are in a FINISHED STATE. How retarded would it be if we demanded people to refilm their movies eternally so they don't seem "abandoned" when they are perfectly finished already. (make no mistake, Crapple breaks their APIs and deprecates them all the time, but at least in that case, it's only CrossOver which needs to change to adapt to the new shitty APIs, the Windows APIs remain the same since Windows is a proper platform so stuff will still work just as before -- but this case is worse)

I hope CrossOver finds a hack to workaround it, in worst case bundling all required libraries by itself. Should teach Crapple a lesson.

Fuck Apple.
Post 10 Feb 2018, 13:35
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 15793
Location: Misner space


Furs wrote:
There's nothing wrong with, for example, older software or games, just like there's nothing wrong with older movies ...

I 100% agree. Age shouldn't be a determining factor to judge software. Bits don't go rusty or become weak with age. Some of the best games I have ever played were the "old" text adventure ones. Which were clever, interesting, funny, well thought out, and make me think. They didn't need any fancy graphics, gigs of RAM, multi-core CPUs, or more than two colours.


Last edited by revolution on 11 Feb 2018, 18:29; edited 1 time in total
Post 10 Feb 2018, 14:00
View user's profile Send private message Visit poster's website Reply with quote
TmX



Joined: 02 Mar 2006
Posts: 813
Location: Jakarta, Indonesia


Furs wrote:

Fuck Apple.



Don't use macOS then. Well, unless you're a:

  • iOS dev
  • Musician/web developer/photographer
  • Businessman who want to use something cooler than Windows, but intimidated by Linux/BSD
  • Apple fanboys who enjoy spending time at coffee shops and taking pictures of their Apple gears


Simple, eh? Smile
Post 10 Feb 2018, 17:58
View user's profile Send private message Reply with quote
Furs



Joined: 04 Mar 2016
Posts: 1155

Hmm? I never used a Mac and never will. Something tells me you didn't read my post properly.

To keep it short: a software I use on Linux is backed mostly by revenue from its Mac version commercial counterpart, and this software is used by people to run Windows software (mostly 32-bit games on Mac, mind, since Mac is terrible at gaming "natively" -- can't blame game devs for hating it, either, since it's so volatile and requires so much maintenance).

So, if this stops working, revenue will drop off, thus it will impact the app I use since it will receive less backing from the commercial Mac version. Yeah, there's a commercial Linux version but stats wise it's like 5% vs 95% revenue, not good.
Post 10 Feb 2018, 21:31
View user's profile Send private message Reply with quote
TmX



Joined: 02 Mar 2006
Posts: 813
Location: Jakarta, Indonesia

Sorry, just re-read your post. Last night I was kinda sleepy.


Quote:

I hope CrossOver finds a hack to workaround it, in worst case bundling all required libraries by itself. Should teach Crapple a lesson.



Not sure whether this could deliver a strong impact on Cupertino, though.
Smile
Post 11 Feb 2018, 01:03
View user's profile Send private message Reply with quote
rugxulo



Joined: 09 Aug 2005
Posts: 2279
Location: Usono (aka, USA)


revolution wrote:

Furs wrote:
There's nothing wrong with, for example, older software or games, just like there's nothing wrong with older movies ...

I 100% agree. Age shouldn't be a determining factor to judge software. Bits don't go rusty or become weak with age. Some of the best games I have ever played were the "old" text adventure ones. Which where clever, interesting, funny, well thought out, and make me think. They didn't need any fancy graphics, gigs of RAM, multi-core CPUs, or more than two colours.



It's relatively easy to support textual, turn-based games (e.g. Rogue or NetHack). I'm no game developer, but I imagine that timing / speed issues are always a pain. How do you do that portably? Not to mention that most modern games forcibly require hardware-accelerated graphics (and/or always-on network and/or DRM). The bloat has gone up tremendously with advent of HD/UHD graphics (and much higher budgets to cope with voice acting, cutscenes, dialogue/story, etc).

Games, like all programs, are a giant mess due to dependencies on OSes, APIs, cpus, peripherals, compilers, libraries, etc. There are too many old DOS games to mention, and yet they aren't supported (except via third-party emulators like DOSBox). Hey, I like DOSBox, but it's incredibly sad that it's even needed (on Windows, esp. 32-bit!).

But modern games aren't really portable either (see here). And AMD64 is the new DOS, everyone foolishly puts all their eggs into one basket. Then again, it's not like major gaming consoles care about backwards compatibility anyways. They mostly only want new sales, not trying to run old stuff. There's actually a thriving retro community with clone consoles, but even that is often harder to get working than it should be. (Also WINE is cool.)

Also, take DOSEMU as an example. It runs on 64-bit Linux too, but it's very very slow (without VT-X, which is a relatively new feature there). Well, 32-bit stuff like DJGPP is native speed, but the 16-bit stuff has to be slowly emulated. It's embarrassing (or infuriating when x64 fanboys always say "more registers!!! always faster!!! kill IA-32!!!!").

"It was the best of times, it was the worst of times ...."
Post 11 Feb 2018, 18:16
View user's profile Send private message Visit poster's website Reply with quote
rugxulo



Joined: 09 Aug 2005
Posts: 2279
Location: Usono (aka, USA)


rugxulo wrote:
AMD64 is the new DOS, everyone foolishly puts all their eggs into one basket. Then again, it's not like major gaming consoles care about backwards compatibility anyways. They mostly only want new sales, not trying to run old stuff.



I just don't personally see the point of developing some brilliant piece of software that won't run on any new/modern machines after five years (which is relatively short term). But portability is hard work (see here or here). You have to basically minimize and separate everything, treating everything as volatile. GCC? Can't rely on it. GNU Make? Also can't rely on it. SDL 1.x? Nope, 2.x obsoletes it. OpenGL? Nope, Vulkan is all the rage. C++11? Too old, try '17. Windows XP? Long dead. Android? Good luck!

There should be two tiers: stable and experimental, and we shouldn't have to upgrade stable for several (five?) years. Let the geeks have their chaos, but let the rest of us have some peace and quiet. This means not constantly updating to latest C++ or graphics API or file system or whatever.

Sure, gaming consoles exist, but they don't last very long anymore (and often have minor refreshes). Some people keep saying "consoles are dead, PC master race!!!1", but I hope that never happens. Too unstable, even if there is 1% hardware improvement in whatever area.

At some point (or maybe already??), 80% of all software will be orphaned with no working platform to run the code. What good is software that can't run? I'm not saying everything must be OSI/FSF, but seriously, what is the answer? The insatiable craving for newer (incompatible) hardware has to stop somewhere. (Even BIOS/CSM will be dead by 2020. VMs can hopefully mitigate that, but it's still sad.)
Post 11 Feb 2018, 18:38
View user's profile Send private message Visit poster's website Reply with quote
TmX



Joined: 02 Mar 2006
Posts: 813
Location: Jakarta, Indonesia


rugxulo wrote:
"consoles are dead, PC master race!!!1"



I assume they are willing to spend more $$$ to build the ultimate gaming PC?
Consoles are, well they just work. And cheaper. Wink
Post 12 Feb 2018, 04:21
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 15793
Location: Misner space


TmX wrote:
Consoles ... they just work.

I thought that was Apple's slogan.

TmX wrote:
And cheaper.

Oh, definitely not Apple's slogan.

Wink
Post 12 Feb 2018, 04:23
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 15793
Location: Misner space


rugxulo wrote:
At some point (or maybe already??), 80% of all software will be orphaned with no working platform to run the code. What good is software that can't run? I'm not saying everything must be OSI/FSF, but seriously, what is the answer? The insatiable craving for newer (incompatible) hardware has to stop somewhere. (Even BIOS/CSM will be dead by 2020. VMs can hopefully mitigate that, but it's still sad.)

Gotta have the latest new shiny thing. Old is common and boring, new is exciting and clearly better. Sad

Actually is is not just computers that suffer from this problem. I know that bicycles are the same. Probably cars also. But computers are kind of in a special place where something 50 years ago (not really "old" IMO, but not recent either) wouldn't have a chance of doing everyday contemporary tasks, whereas bicycles and cars from 50 years ago can still perform their needed tasks of today if they are properly maintained.
Post 12 Feb 2018, 07:48
View user's profile Send private message Visit poster's website Reply with quote
Furs



Joined: 04 Mar 2016
Posts: 1155


rugxulo wrote:
It's relatively easy to support textual, turn-based games (e.g. Rogue or NetHack). I'm no game developer, but I imagine that timing / speed issues are always a pain. How do you do that portably? Not to mention that most modern games forcibly require hardware-accelerated graphics (and/or always-on network and/or DRM). The bloat has gone up tremendously with advent of HD/UHD graphics (and much higher budgets to cope with voice acting, cutscenes, dialogue/story, etc).

Games, like all programs, are a giant mess due to dependencies on OSes, APIs, cpus, peripherals, compilers, libraries, etc. There are too many old DOS games to mention, and yet they aren't supported (except via third-party emulators like DOSBox). Hey, I like DOSBox, but it's incredibly sad that it's even needed (on Windows, esp. 32-bit!).

Yeah, DRM is a pain, sometimes it's the only reason a game doesn't work on a newer system, because it uses a crappy protector or whatever that relies on pathetic assumptions instead of good coding practice. (wine devs especially know the intricate pains of dealing with this). It's cool that GOG usually brings a patched, DRM-free version of the game so that it has much more chances to work.


rugxulo wrote:
Also, take DOSEMU as an example. It runs on 64-bit Linux too, but it's very very slow (without VT-X, which is a relatively new feature there). Well, 32-bit stuff like DJGPP is native speed, but the 16-bit stuff has to be slowly emulated. It's embarrassing (or infuriating when x64 fanboys always say "more registers!!! always faster!!! kill IA-32!!!!").

First time I hear of DOSEMU, how does it compare with DOSBOX? BTW I know what you mean and agree, especially funny when I see people say 1TB of space is nothing these days to them, yet they make a huge deal about "cruft" that they want "removed" because they don't use those features that barely take a few MBs... quite pathetic to me (and it's not always about backwards compatibility, I mean literally, even features that are not "popular" enough, such as support for a format or plugin API, they want them removed, fucking idiots piss me off)

As for timing, that's why APIs should be used that don't break. Sure, on one system the API may call a timer that doesn't exist on another under the hood, but at least the implementation of the API can be changed (or even as a compatibility layer, like Wine does) with the interface staying the same. This way only one software has to change (the OS or Wine etc) while the games will be perfectly functional.

Crapple doesn't seem to understand the API part. Actually, many GPL "Linux" libraries don't understand the API part either. Look at the GTK3 fiasco. However, on Linux you can statically link or deploy the libraries with the app, because they will always work, since the Linux kernel never breaks userland APIs. So even on Linux it's easier to ship an app without requiring non stop maintenance.

(speaking of GTK3, how is it possible for an API to break so fucking much is beyond me, do some "programmers" not understand what a DESIGN PLAN is? Jesus)
Post 12 Feb 2018, 13:08
View user's profile Send private message Reply with quote
rugxulo



Joined: 09 Aug 2005
Posts: 2279
Location: Usono (aka, USA)


Quote:

First time I hear of DOSEMU, how does it compare with DOSBOX?



DOSEMU actually dates back to (AFAIK) 1992 whereas DOSBox first released circa 2002 or so.

DOSBox is a slow, software-only emulator with its own fake DOS, only for games. Default emulation is a "fast" 486 and 16 MB of RAM. I think maximum is "slow" Pentium and 64 MB of RAM. It's GPL (and builds with Free/libre tools) and portable to non-x86 arches (thanks to using SDL). But it hasn't had a major release lately, and there are many unofficial forks.

DOSEMU uses the host x86 cpu, so it's not limited to (old) 486 or 586 opcodes. Thus, it's very fast (usually). It uses a real DOS (e.g. FD- or DR- or MS-), and it too can mount native file systems for easy access to files. It's not quite as good for various soundcard emulations, but it does sometimes work.

But DOSEMU has somewhat languished, despite supporting FreeDOS, due to using "non-free build tools", thus it has not been widely propagated among strict Linux distros in recent years. But that has been (thankfully) changing lately (see FOSDEM video from last week).


Quote:

BTW I know what you mean and agree, especially funny when I see people say 1TB of space is nothing these days to them, yet they make a huge deal about "cruft" that they want "removed" because they don't use those features that barely take a few MBs... quite pathetic to me (and it's not always about backwards compatibility, I mean literally, even features that are not "popular" enough, such as support for a format or plugin API, they want them removed, fucking idiots piss me off)



Self-proclaimed geeks love to declare technology "dead". I don't know why, but they are obsessed with doing that. "Perl is dead", "OpenGL is dead", etc. It's not the same as saying "XP is dead" (which is partially true). They just want to obsolete and throw away lots of things, which is not always wise.


Quote:

As for timing, that's why APIs should be used that don't break.

Crapple doesn't seem to understand the API part. Actually, many GPL "Linux" libraries don't understand the API part either. However, on Linux you can statically link or deploy the libraries with the app, because they will always work, since the Linux kernel never breaks userland APIs. So even on Linux it's easier to ship an app without requiring non stop maintenance.



Chaos rules, sadly. Strict binary compatibility (esp. proprietary) is really bad sometimes while the freedom to change (and break) sources endlessly is also tedious and error-prone.

I think it's a mistake to rely on prebuilt binaries (if you can help it), but rebuilding things (or even bootstrapping) is ridiculously overcomplicated. There is an art to minimalism (Minix? Menuet? SanOS?), but it takes a lot of work.
Post 12 Feb 2018, 20:52
View user's profile Send private message Visit poster's website Reply with quote
Furs



Joined: 04 Mar 2016
Posts: 1155

DOSEMU sounds more like a virtualizer than an emulator like DOSBOX, quite ironic since it has EMU in its name. Razz
Post 13 Feb 2018, 13:30
View user's profile Send private message Reply with quote
Coty



Joined: 17 May 2010
Posts: 540
Location: ␀

I'm going to be the odd one out. It's okay if apple drops support for 32bit applications (But not for okay Microsoft). Why? People forget apple used IBMs Power PC architecture until 2005 (in the note nooks) and 2006 (In the desktops).

2005 and 2006 are the called the transitional period. Apple started off in 2005 by offering early intel core series CPUs in the MacBook with a single or daul core option. This chips were all 32bit. While as all the desktop models continue to use the PPC G5 chip.

in 2006 Apple released a completely refabbed line up. This new line up offered nothing other than x86-64 CPUs across the board.

Thus... You could really only buy a 32bit x86 based mac for about a year. So 32bit applications have always been a little on the slim side as far as 3rd party applications are concerned... Plus some of them no longer run properly because things have changed in the OS over the years (for better or worse, one could always argue that things like that need to have better legacy support, while one could also argue, that security is better than legacy.)

Plus if the rumors of Apple possibly switching to their ARM based chips in their notebooks yields any merit, I could see why apple would want to minimize their compatibility chain.
Post 14 Feb 2018, 14:50
View user's profile Send private message Send e-mail Visit poster's website AIM Address Reply with quote
Furs



Joined: 04 Mar 2016
Posts: 1155

Except you can run Windows applications on Mac with CrossOver or Wine.
Post 14 Feb 2018, 15:19
View user's profile Send private message Reply with quote
Coty



Joined: 17 May 2010
Posts: 540
Location: ␀

I haven't used wine in a few years. Personally I switched to mac after 5 years of using linux because I started free-lance photography/cinematography and wanted a Unix environment that natively supported the software I needed. Adobe light room, photoshop and Premier. Ever since I have never once needed wine for anything, but I have no doubt it can adapt. (If it even relies on "legacy" 32bit support from the OS in the first place).

That said I COMPLETELY understand the need for wine in a linux environment. Linux has allot of really good open source software. But it's super lacking when it comes to good commercial software (the very thing that drove me to a mac in the first place).

But I still hold my statement. I'm sure wine can adapt either by dropping mac support (steam support is now huge for macs and still growing, so wine/crossover is fading on the platform anyway.) Or maybe it will adapt in a better way going as far as to provide support for 32bit software on "non compatible" versions of MacOS(X).
Post 14 Feb 2018, 15:58
View user's profile Send private message Send e-mail Visit poster's website AIM Address Reply with quote
Furs



Joined: 04 Mar 2016
Posts: 1155

Well if CrossOver drops Mac support their business might fail, unless Linux picks up (which would be cool for Linux, but I'm realistic here, it's more likely the users will just turn to Windows... meh). Sad
Post 15 Feb 2018, 13:46
View user's profile Send private message Reply with quote
rugxulo



Joined: 09 Aug 2005
Posts: 2279
Location: Usono (aka, USA)


Furs wrote:
DOSEMU sounds more like a virtualizer than an emulator like DOSBOX, quite ironic since it has EMU in its name. Razz



Quoting from the slides at recent FOSDEM talk:


Quote:

Still nice for doing compile jobs inside DOSEMU, e.g.
COMMAND.COM: 9.5 secs with KVM, 57 secs with JIT CPU
emulation, 4 mins with simulated CPU emulation.

Post 15 Feb 2018, 19:59
View user's profile Send private message Visit poster's website Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  
Goto page 1, 2  Next

< Last Thread | Next Thread >

Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You can attach files in this forum
You can download files in this forum


Main index   Download   Documentation   Examples   Message board
Copyright © 2004-2018, Tomasz Grysztar.
Powered by rwasa.