Win32 on macOS(winehq.org)
winehq.org
Win32 on macOS
https://www.winehq.org/pipermail/wine-devel/2019-December/156602.html
136 comments
The Codeweaver folks are really great. I worked with one of their engineer's brother, which is how I can to discover this local (for me) company. The Linux version of WINE really shines too. They track, fix, and give back to the open source project while taking care of all the setup, etc. Ironically, a Win95 Garmin GPS simulator (airplane instrument) worked lovely on their kit... while it would not work on the 'run as' on Windows 7.
I've got their OSX version as well. There was a day where I needed Visio at work, and that would let me launch a Windows bottle. Funny enough, it also ran quite a few steam games... back before there were solid OSX ports for what I'd play.
I've got their OSX version as well. There was a day where I needed Visio at work, and that would let me launch a Windows bottle. Funny enough, it also ran quite a few steam games... back before there were solid OSX ports for what I'd play.
I find it marvelous you can reliably use software 24 years later. And we talk about binaries, not sources. And we talk about software still with business uses.
The original storage media may be corrupted but the software lives!
My personal belief is Wine will stand next and maybe above the GNU project, the Linux kernel, the QEMU emulator and the GIT version management as the best things ever made by free software.
The original storage media may be corrupted but the software lives!
My personal belief is Wine will stand next and maybe above the GNU project, the Linux kernel, the QEMU emulator and the GIT version management as the best things ever made by free software.
Did you see this from previous Christmases? https://www.qemu-advent-calendar.org/2018/ (change the last digit to 6 or 4 to see previous Advent calendars) I think we have to wait 'til next year for the next one.
They're pretty great, and do a great job showing off the many platforms it can emulate, in a way that feels and rewards like a treasure hunt.
They're pretty great, and do a great job showing off the many platforms it can emulate, in a way that feels and rewards like a treasure hunt.
> running Win32 executables in the MacOS hypervisor framework
Interesting, why was this discarded? Performance reasons? Or the API not being satisfactory?
Interesting, why was this discarded? Performance reasons? Or the API not being satisfactory?
Presumably performance. At that point just use Virtualbox/VMWare.
How long will it exist?
IDK, a long time I'd suppose?
The oldest programs I can use reliably are win32 inside wine.
It may not be what you think is technically the best, but office 2007 works well and many games and other specialized too. The office license is cheap and does most of what I need.
Someone mentionned below, a perpetual license of Mathematica for MacOSX will be useless in a year, because of the deprecation. Their mistake was not buying the Windows version.
That's why I still buy win32 software to this day. Their binaries will work on anything for a long time.
The oldest programs I can use reliably are win32 inside wine.
It may not be what you think is technically the best, but office 2007 works well and many games and other specialized too. The office license is cheap and does most of what I need.
Someone mentionned below, a perpetual license of Mathematica for MacOSX will be useless in a year, because of the deprecation. Their mistake was not buying the Windows version.
That's why I still buy win32 software to this day. Their binaries will work on anything for a long time.
I think they mean:
> How long will [the MacOS hypervisor framework] exist?
> How long will [the MacOS hypervisor framework] exist?
I think this is right. But I don't see any reason to believe the hypervisor APIs are in danger, unless I'm missing something.
That’s a great point! I’m bummed about 32bit ports of old games that won’t work anymore.
There must be open source editors available that have feature parity with 12yo software.
Wine opens many new usecases. You realize the software rot myth was created by bad API deprecation pratices.
Think how different the market becomes when consumers can keep using a 12 years old license. You need to introduce fantastic new features to get my money. Changing the font, the menu and the colors won't do.
Even if it is free - why should I bother to learn this new software? The old license did cost me $5. If I misplace it, I can buy another for the same amount instead of paying year to year. And to this day it works reliably on every operating system I use.
Think how different the market becomes when consumers can keep using a 12 years old license. You need to introduce fantastic new features to get my money. Changing the font, the menu and the colors won't do.
Even if it is free - why should I bother to learn this new software? The old license did cost me $5. If I misplace it, I can buy another for the same amount instead of paying year to year. And to this day it works reliably on every operating system I use.
Well, then get to work.
Dethroning MS Office is going to be a long, hard battle, and it seems like not very many people are interested in fighting it.
Dethroning MS Office is going to be a long, hard battle, and it seems like not very many people are interested in fighting it.
> nothing but email and IRC
But? Those are both extremely capable communication mechanisms.
But? Those are both extremely capable communication mechanisms.
I read "nothing but email and IRC" to mean "without in-person meetings" as opposed to "without more capable communications tools".
Or without voice chat.
Although coding over voice/video chat isn’t fun.
Although coding over voice/video chat isn’t fun.
Exactly. When people are motivated to work together, even poor communication tools are adequate. But these are excellent communication tools.
> Speaking of code segments, the big thing that Catalina provides that enables this all to work is the ability to create 32-bit code segments in a 64-bit process. For that, they enabled the use of i386_set_ldt() in 64-bit processes. The big caveat though, is that this functionality is restricted by System Integrity Protection (SIP). For now, your best bet to get this working for yourself is to disable SIP. (CrossOver doesn't require that, but the mechanism by which we accomplish that is in flux internally to Apple. When it settles down, I'll update this thread.)
This is quite curious. Apple inconvenienced so many users by "removing" 32-bit support on Catalina, and then they added support for local descriptor tables? I'm not aware of any use of LDTs on modern systems (except perhaps Chrome for additional sandboxing).
This is quite curious. Apple inconvenienced so many users by "removing" 32-bit support on Catalina, and then they added support for local descriptor tables? I'm not aware of any use of LDTs on modern systems (except perhaps Chrome for additional sandboxing).
> This is quite curious. Apple inconvenienced so many users by "removing" 32-bit support on Catalina, and then they added support for local descriptor tables? I'm not aware of any use of LDTs on modern systems (except perhaps Chrome for additional sandboxing).
For the specific purpose of enabling CrossOver's 32-on-64 support and things like it.
It's not too hard for the kernel to support user code merely entering the processor's 32-bit mode. CrossOver's processes don't even use 32-bit system calls or 32-bit Mach-O binaries, so support for those could hypothetically be removed, except that most of it is needed for watchOS anyway. But the most significant cost of i386 support was in userland, not the kernel: building separate x86_64 and i386 copies of every system library, and supporting the legacy i386 ABI, including an older version of the Objective-C runtime ABI. That's all gone now.
For the specific purpose of enabling CrossOver's 32-on-64 support and things like it.
It's not too hard for the kernel to support user code merely entering the processor's 32-bit mode. CrossOver's processes don't even use 32-bit system calls or 32-bit Mach-O binaries, so support for those could hypothetically be removed, except that most of it is needed for watchOS anyway. But the most significant cost of i386 support was in userland, not the kernel: building separate x86_64 and i386 copies of every system library, and supporting the legacy i386 ABI, including an older version of the Objective-C runtime ABI. That's all gone now.
I am not privy to internal discussions, but it seems to me if there is really lots of ongoing maintenance needed at every release, and not simply exaggerating the need for occasional patches and bug fixes, then it is worth some consideration of re-architecting the way the compatibility mode works.
eg. Maybe draw the boundary of where you thunk at a different place. Maybe do more translation in user mode as this wine project did. Or focus on binary compatibility with old, frozen-in-time frameworks instead of rebuilding them with every OS build. Obviously the specifics will vary with actual details of breakage. But from outside, it seems like these type of questions weren't pursued to their maximum extent, resulting in pain for the end user.
eg. Maybe draw the boundary of where you thunk at a different place. Maybe do more translation in user mode as this wine project did. Or focus on binary compatibility with old, frozen-in-time frameworks instead of rebuilding them with every OS build. Obviously the specifics will vary with actual details of breakage. But from outside, it seems like these type of questions weren't pursued to their maximum extent, resulting in pain for the end user.
Apple has some weird history with doing crazy things with 32b/64b stuff just because they can - back in the Intel 64 early days they ran a 64-bit kernel that loaded 32-bit device drivers. I don't know if anyone has still figured out the how and why of it!
They didn’t load 32-bit drivers in a 64-bit kernel; rather they ran a 32-bit kernel that supported 64-bit userspace processes.
You may be right but I remember both of those things - supporting 64-bit apps on 32-bit kernel and loading kexts that didn't bit-match the kernel. Long time ago so not sure.
Non-matching kexts was never a thing.
[deleted]
That's even crazier. How and why??
When the first 64 bit Macs shipped none of the software was 64 bit clean. Even if the kernel source code had been 64 bit clean, it would have broken support for all the the 3rd party 32 bit drivers that existed.
So the kernel switched itself in 32 bit virtual mode, though some parts of the pmap layer understood 64 bit page tables in order to manage the 64 bit physical address space. While the kernel could not see all of memory, it did not need to, it could map any apertures it needed in by manipulating its own page tables.
At that point it is pretty trivial to setup a 64 bit address space for a process. The kernel could not directly map all of virtual address range of the process at once, but it already had the pmap and aperture management code to deal with that. That decoupled 64 bit user space bringup from the 64 bit kernel port. The first release that supported 64 bit processes did not have 64 bit UI frameworks, just the C library and some low level posix functionality, but it allowed scientific code that benefited from more memory to run.
So the kernel switched itself in 32 bit virtual mode, though some parts of the pmap layer understood 64 bit page tables in order to manage the 64 bit physical address space. While the kernel could not see all of memory, it did not need to, it could map any apertures it needed in by manipulating its own page tables.
At that point it is pretty trivial to setup a 64 bit address space for a process. The kernel could not directly map all of virtual address range of the process at once, but it already had the pmap and aperture management code to deal with that. That decoupled 64 bit user space bringup from the 64 bit kernel port. The first release that supported 64 bit processes did not have 64 bit UI frameworks, just the C library and some low level posix functionality, but it allowed scientific code that benefited from more memory to run.
Apple started working on 64-bit application support back when they were still on PowerPC, where they only had 64-bit for desktop processors, not laptops. Then the first round of Intel Macs had 32-bit Core Duo processors. Less than a year later the second round introduced 64-bit Core 2 Duo processors that were pretty much a drop-in replacement, and at the time it certainly didn't make sense for Apple to overhaul their EFI, kernel and drivers with a 64-bit transition only 9 months after switching from PPC to x86.
Support for 64-bit GUI applications on OS X didn't arrive until 2007, a year after Intel Macs started using 64-bit processors. Support for running a 64-bit kernel arrived in 2009, and only for machines that had 64-bit EFI firmware. In 2012, Apple dropped support for the machines that had 64-bit processors but used 32-bit EFI, so from that point on they were handling the 64/32-bit mix the same as other operating systems.
Support for 64-bit GUI applications on OS X didn't arrive until 2007, a year after Intel Macs started using 64-bit processors. Support for running a 64-bit kernel arrived in 2009, and only for machines that had 64-bit EFI firmware. In 2012, Apple dropped support for the machines that had 64-bit processors but used 32-bit EFI, so from that point on they were handling the 64/32-bit mix the same as other operating systems.
Maybe they plan on doing a big show and dance when they “settle” the issues around SIP: “macOS now allows you to run classic apps and games!!!!”
Does apple have a good reason for killing 32bit support? I play a number of games that will now never run without a VM.
The obvious development reason is to simplify and unify the code base, tools, and build process across all of their platforms. 32-bit bugs can also be ignored/deleted for future versions.
The obvious hardware reason on iOS is that Apple can remove support for ARM32.
The obvious business reason is to encourage subscriptions to Apple Arcade.
The obvious hardware reason on iOS is that Apple can remove support for ARM32.
The obvious business reason is to encourage subscriptions to Apple Arcade.
How is Arcade related to 32-bit?
[deleted]
Lots of games are 32-bit.
And just to fully complete the thought, I believe the GGP is implying "Break existing Mac games, so that people who want to play games on their Mac have to subscribe to Apple Arcade."
https://pilky.me/apples-technology-transitions/
Section "Why Drop 32 Bit?" (last quarter of the article).
Section "Why Drop 32 Bit?" (last quarter of the article).
"when you open a 32 bit app, 32 bit system libraries remain loaded forever!" okay how about you fix that instead?
Simplifying the software and hardware. Seems a good thing to clear out the cruft? Use a VM if you need to emulate ancient systems.
Probably a step towards the eventual arm64 transition.
Killing it in the way they did? Not a dire technical one. In the past they managed to keep compatibility while switching operating systems ("Classic") and CPU architectures (68k -> PPC, PPC -> Intel). And that while being a much smaller company.
This is business, nothing else. Just like all the increased "security" restrictions. Corralling everyone towards the App Store. I think they've got too much legacy to ever totally cut off "regular" applications, but apart from that they're doing everything they can to move everything in the direction of iOS (or iPadOS now).
Not sure how long the days of the last commercial Unix will last.
This is business, nothing else. Just like all the increased "security" restrictions. Corralling everyone towards the App Store. I think they've got too much legacy to ever totally cut off "regular" applications, but apart from that they're doing everything they can to move everything in the direction of iOS (or iPadOS now).
Not sure how long the days of the last commercial Unix will last.
> In the past they managed to keep compatibility while switching operating systems ("Classic") and CPU architectures (68k -> PPC, PPC -> Intel).
The Classic Environment (OS 9 -> OS X) was dropped after 6 years.
Rosetta (PPC -> i386) was dropped after 5 years.
i386 -> x86_64 is now being dropped after 12 years.
The Classic Environment (OS 9 -> OS X) was dropped after 6 years.
Rosetta (PPC -> i386) was dropped after 5 years.
i386 -> x86_64 is now being dropped after 12 years.
Your point notwithstanding, the big difference to me is this: Classic and Rosetta were hacks with sucky UX. In particular, performance was terrible, in Rosetta because it was a full on CPU emulator, and Classic because it was booting Mac OS 9 in a Virtual Machine. Apps that used Classic also looked visually out of place.
Running 32 bit apps in Mac OS X Mojave is 100% seamless to the user—if it wasn't for Apple's warning dialogues that 32bit was going to be deprecated, most users—even advanced users—would never even know the app was 32 bit.
And that's because 32 bit support is a key feature of the amd64 architecture—it's the main reason most computers today use amd64 instead of the alternate standard proposed by Intel.
Running 32 bit apps in Mac OS X Mojave is 100% seamless to the user—if it wasn't for Apple's warning dialogues that 32bit was going to be deprecated, most users—even advanced users—would never even know the app was 32 bit.
And that's because 32 bit support is a key feature of the amd64 architecture—it's the main reason most computers today use amd64 instead of the alternate standard proposed by Intel.
Killing it in the way they did? Not a dire technical one. In the past they managed to keep compatibility
Killing it in what way? They kept compatibility for years and eventually ended it, just like the transitions you mention.
This is business, nothing else
Both the security changes and dropping 32 bits are technically reasonable things to do. You might not like them and that's perhaps not entirely unreasonable either but the notion that they were done for business, nothing else makes little sense. What business do you have in mind? Apple makes money selling iPhones.
Killing it in what way? They kept compatibility for years and eventually ended it, just like the transitions you mention.
This is business, nothing else
Both the security changes and dropping 32 bits are technically reasonable things to do. You might not like them and that's perhaps not entirely unreasonable either but the notion that they were done for business, nothing else makes little sense. What business do you have in mind? Apple makes money selling iPhones.
I'd guess a translation layer would require much more effort to develop and maintain than just keeping 32 bit support. It wouldn't make much sense in this case because dropping support is the sole objective, not some side effect caused by architectural/OS changes.
I was just mentioning those layers as something Apple was able to do if they wanted to keep being compatible. They could, but they don't want. How sinister that purpose is, is up to the reader...
Apple has a long history of sunsetting various technologies, so I don't know how this is different. Their solution to tech debt is often to just deprecate the edge cases -- which is probably the right decision.
It’s like the exact opposite approach that Microsoft seems to take with Windows, and a key reason that I prefer Apple/MacOS
Yeah, Apple tried to take the Microsoft approach with the Mac Clones in the late 90s and it failed spectacularly because it's just not in their DNA to be a tech company. They're a product company that hates managing technology longer than is absolutely necessary.
> This is business, nothing else.
That's entirely the case. Apple has to weigh the cost of maintaining compatibility against the value it brings.
And it's hard to see how if the developer can't make a business case for updating their software that Apple can make a business case for maintaining compatibility.
That's the business reality of Apple's primarily consumer market: consumers are generally willing to let old software go and buy new stuff.
Microsoft is simply in a different market: they have many large enterprise customers who are willing to pay top dollar for extensive backwards compatibility.
That's entirely the case. Apple has to weigh the cost of maintaining compatibility against the value it brings.
And it's hard to see how if the developer can't make a business case for updating their software that Apple can make a business case for maintaining compatibility.
That's the business reality of Apple's primarily consumer market: consumers are generally willing to let old software go and buy new stuff.
Microsoft is simply in a different market: they have many large enterprise customers who are willing to pay top dollar for extensive backwards compatibility.
Apple has supposedly been “corralling every one” to the Mac App Store for a decade. Isn’t it more likely that the conspiracy theories are wrong?
Remember on 68k they also had to orchestrate the transition from 24-bit to 32-bit addressing.
I remember using some Connectix gadget on a IIcx to make it able to address 32 bits. I spent some time in macsbug figuring out how it worked. It was really interesting. It essentially patched the memory manager early in the boot process then forced it to reinitialize itself.
I'm pretty sure Apple licensed that for some version of System 7 (maybe 7.5.something?) so that they could assume all post-boot 32-bit macs were 32-bit clean.
I'm pretty sure Apple licensed that for some version of System 7 (maybe 7.5.something?) so that they could assume all post-boot 32-bit macs were 32-bit clean.
The Classic environment was retired in 2007 with the release of 10.5 Leopard, and was never available for x86 Macs. With 10.7 Lion (2011), they dropped support for 32-bit x86 Macs, and running PowerPC software via emulation (Rosetta). Eight years of support for 32-bit apps is quite long by these standards.
My speculation is that it's for the upcoming arm64 transition (yet another speculation). It's easier to make one emulator, than two.
This is a great feat and it creates a somewhat ironic situation: When I want to run an app on Catalina that happens to be 32-bit only, I'm practically forced to use the Windows version. I can't see how that was a smart move on Apple's side.
Could some of the wizardry described here be used to get native 32-bit software working again?
As I understand it, this would only be possible if you recompiled the software with the modified Clang they use for the Windows apps (and the underlying tech is in a state of flux). I'm not sure that would be more expedient than rebuilding your app as 64-bit.
The system frameworks you’d depend on don’t have a 32-bit slice anymore, unfortunately. You’d need to wrap every function in a think to make things work.
> You’d need to wrap every function in a think to make things work.
I think you meant “thunk”.
I think you meant “thunk”.
I did but AutoCorrect unfortunately thunk differently.
The unthinkable has been thunk. Who'd a thunk it?
Not sure how long this would work but the trick is to copy the 32 bit shared libraries over: https://apple.stackexchange.com/a/374038
It's apparently straightforward to install - an old - macOS in a VM. This can then be used to obtain the dylibs
It's apparently straightforward to install - an old - macOS in a VM. This can then be used to obtain the dylibs
The writing that 32bit apps are going away was on the wall for a long time. If you still rely on that (maybe for some enterprise application) then you are probably not going to upgrade to the newest version right away anyway.
It’s like removing the floppy drive, there will be a bunch of people complaining (probably the 1%) who still use it but in the end everyone is better of without it and it will be replaced by something better.
Almost nobody of the general users would know a difference between 32 / 64 bit as they just use new apps or use web apps. It’s a very small group that’s affected by this change.
It’s like removing the floppy drive, there will be a bunch of people complaining (probably the 1%) who still use it but in the end everyone is better of without it and it will be replaced by something better.
Almost nobody of the general users would know a difference between 32 / 64 bit as they just use new apps or use web apps. It’s a very small group that’s affected by this change.
The writing has been on the wall for a long time but some big name software companies are slow to adapt, and even if they adapted you'll probably have to pay good money for a new license.
Take Mathematica for example. The first 64-bit version is 12.0, released April 2019. So a year-old permanent v11 license is useless on Catalina now. It would have cost me a couple hundred bucks to upgrade my v9 permanent license if I didn't happen to have an institutional license.
Take Mathematica for example. The first 64-bit version is 12.0, released April 2019. So a year-old permanent v11 license is useless on Catalina now. It would have cost me a couple hundred bucks to upgrade my v9 permanent license if I didn't happen to have an institutional license.
Sounds like you ought to get mad at Mathematica for selling 32bit MacOS software in 2019, which it's been well known for over a decade that support will eventually be dropped.
Hardly been "well known for over a decade". A decade ago, Rosetta was well-supported. The dropping of Rosetta support in Lion was quasi-abrupt, but understandable (it arose from a licensing concern after the tech was acquired). The 32/64 transition was announced a few years ago, but it was hardly something known a decade ago.
The history of Apple suggests that when they come out with a new development environment, it is well advised to just go ahead an make that switch as soon as possible. Even if they make a bandaid type of stepping stone like Rosetta, don't lean on it permanently. Adobe had to skip an entire version of their software suite because they didn't believe Apple was serious.
The last 32 bit Mac was released in 2007.
If the last 32 bit Mac that Apple shipped was over a decade ago, why wouldn’t you port your code to 64 bit?
What wrong with running decade old software? What if the company is long gone? Apple is forcing me to never upgrade.
In the grand scheme of things, how many companies do you think wrote software for the Intel based Mac between the beginning of 2006 when the first Intel based Macs were introduced and 2009 when Apple dropped support for 32 bit Macs and then went out of business?
Sounds like an even better reason to force their hand. If it was left to companies, they would still be shipping software with 68K code.
> If it was left to companies, they would still be shipping software with 68K code.
You seem to think that would be a bad thing. Why?
The operating system is there to support applications.
You seem to think that would be a bad thing. Why?
The operating system is there to support applications.
Every piece of code in an operating system means a larger surface area for vulnerabilities, more support cost, more maintenance for both developers and the operating system maintainers, etc.
If you want to see how badly this can go wrong - look at Windows. Over a decade ago there were over a half a dozen different ways to represent a string in Windows and depending on which API you called, you had to translate between them.
Also, one of the earliest widespread vulnerabilities was caused by IIS not checking all of the different types of string encodings. You could literally pass DOS commands via the url bar just by encoding them and they would run on the server.
If you want to see how badly this can go wrong - look at Windows. Over a decade ago there were over a half a dozen different ways to represent a string in Windows and depending on which API you called, you had to translate between them.
Also, one of the earliest widespread vulnerabilities was caused by IIS not checking all of the different types of string encodings. You could literally pass DOS commands via the url bar just by encoding them and they would run on the server.
The logical extension of this belief is to just turn the computer off. That way it's not running any code and is 100% secure.
In the real world there are trade offs. This is engineering 101.
Find me a perpetual license for a version of Adobe Lightroom that has a 64-bit installer and I'll pay for it. But I'm not going to upgrade to a leased tool. Luckily the perpetual Lightroom licenses work on Windows too, so when Mavericks loses support I'll probably migrate at least the photography workflows to wine (on not-macOS though).
Mavericks has been out of support for 3 years JFYI
Mavericks has been out of support for 3 years JFYI
Sorry I meant Mojave or whatever 10.14 is called.
Sorry I meant Mojave or whatever 10.14 is called.
What perpetual license? If you buy a copy of something like CC suite, it was for that current version. If Adobe updates a major upgrade (not point releases), they charged you again for the upgrade. That was usually 12-18 months. That was also $999 for those upgrades. Sure, you could stay on that version, but as the OS upgrades, that code becomes unusable forcing the upgrade. The "lease" licenses is $50/month or $600/yr (usually comes with a discount for the 12month purchase). You get access to the upgrades as they come so you're always current. Where's the evil? Oh, and with that $50/month, I can run it on 2 separate computers simultaneously. The original license was for one computer.
The perpetual license to use the software in the version you bought. Few people truly needed every single version, but instead only upgraded when it became necessary or there was a killer feature they wanted.
You're simply forgetting the fact that as the OS upgrades, the software that is not upgraded cannot be used without also upgrading. What's the last OS that CS6 could be installed?
Also, anyone using Adobe software in a professional setting (meaning actually getting paid for using the software) can easily pay the monthly fees. Staying on an antiquated version of software means they can no longer open files that are created on recent versions of software (thinking Premiere). I have not met one professional that is still holding on to the perpetual license fallacy. The maths just don't add up.
Also, anyone using Adobe software in a professional setting (meaning actually getting paid for using the software) can easily pay the monthly fees. Staying on an antiquated version of software means they can no longer open files that are created on recent versions of software (thinking Premiere). I have not met one professional that is still holding on to the perpetual license fallacy. The maths just don't add up.
Also, anyone using Adobe software in a professional setting (meaning actually getting paid for using the software) can easily pay the monthly fees.
Even if I were getting paid for my photography, why would I want to pay extra fees?
Staying on an antiquated version of software means they can no longer open files that are created on recent versions of software (thinking Premiere).
In the case of Lightroom the only thing that's going to "upgrade" your file format is a new camera body, and that's not something I do all that much. I don't need to open files from people with newer cameras. And, let's face it, if I really need to open newer raw files I can use Adobe's DNG converter.
Lightroom 6 is a 64-bit app with a 32-bit installer. Newer versions of LR offer up a ton of cloud shit I don't want, bundled with more seamless integration for newer cameras I don't own. What am I getting out of monthly payments to Adobe?
The past few upgrades to Lightroom that I've bought were around $80. Well less than a year of the cheapest CC subscription.
Even if I were getting paid for my photography, why would I want to pay extra fees?
Staying on an antiquated version of software means they can no longer open files that are created on recent versions of software (thinking Premiere).
In the case of Lightroom the only thing that's going to "upgrade" your file format is a new camera body, and that's not something I do all that much. I don't need to open files from people with newer cameras. And, let's face it, if I really need to open newer raw files I can use Adobe's DNG converter.
Lightroom 6 is a 64-bit app with a 32-bit installer. Newer versions of LR offer up a ton of cloud shit I don't want, bundled with more seamless integration for newer cameras I don't own. What am I getting out of monthly payments to Adobe?
The past few upgrades to Lightroom that I've bought were around $80. Well less than a year of the cheapest CC subscription.
I’d love to see professional licenses switch to a “maximally fair to the user subscription model”.
If you use the thing in a given month, you autopay the monthly subscription fee — if you don’t use it at all in a given month — you pay nothing.
people who use the software regularly pay basically the current subscription pricing model — but if you only use it very occasionally — you pay much less.
I think this kind of pricing model could really help drive adoption of subscription pricing for professional tools ... I’d be willing to maintain a subscription to several expensive infrequently used by me tools with this kind of pricing model — and I might occasionally use those tools which would be better for the developer than me never using their tool at all ...
If you use the thing in a given month, you autopay the monthly subscription fee — if you don’t use it at all in a given month — you pay nothing.
people who use the software regularly pay basically the current subscription pricing model — but if you only use it very occasionally — you pay much less.
I think this kind of pricing model could really help drive adoption of subscription pricing for professional tools ... I’d be willing to maintain a subscription to several expensive infrequently used by me tools with this kind of pricing model — and I might occasionally use those tools which would be better for the developer than me never using their tool at all ...
I'd like that too, although the pricing steps are an interesting challenge: You want to make the full amount of regular users, but don't want the casual users to think "if I click this icon now to touch one file, it's gonna cost me 20 bucks", so you might need even more granular steps. E.g. a month costs the same as 1/10th of a year, a day costs the same as 1/8th of a month -> if you use it >8 days in a month it caps to the month, if you use it >10 months it caps to the year. Kind of like some public transport network cards work.
I think it goes without saying that not everyone that buys software is a professional, and instead wish to use it a few times per year for job adjacent functions or as a hobbyist. For the "few times a year" folks, maybe "one month at a time is annoying but reasonable enough."
Hobbyists, though, are in a bad spot.
Hobbyists, though, are in a bad spot.
at least Photoshop CS6 runs perfectly fine on a current Windows 10 (I suspect it wouldn't do good with a high-DPI screen though), but I agree that going all the way back to that today is not really something you'd do for regular professional use. Of course, not everyone is a professional user.
That said, freelancers I know using Adobe software have to keep old versions around because clients don't upgrade. People are even now skipping or lagging versions, because they'd rather stay with a version they know works than invite new bugs by upgrading.
That said, freelancers I know using Adobe software have to keep old versions around because clients don't upgrade. People are even now skipping or lagging versions, because they'd rather stay with a version they know works than invite new bugs by upgrading.
> at least Photoshop CS6 runs perfectly fine on a current Windows 10
And on Mojave, by the way. It's only this stupid 32 bit thing that's killing it in Catalina.
> but I agree that going all the way back to that today is not really something you'd do for regular professional use.
Why? Adobe hasn't added anything particularly significant since CS6.
(And I don't think it's a coincidence that they moved to a subscription model around the same time they stopped making significant improvements.)
And on Mojave, by the way. It's only this stupid 32 bit thing that's killing it in Catalina.
> but I agree that going all the way back to that today is not really something you'd do for regular professional use.
Why? Adobe hasn't added anything particularly significant since CS6.
(And I don't think it's a coincidence that they moved to a subscription model around the same time they stopped making significant improvements.)
Why would Apple cafe if you run Windows on the Mac?
It weakens your incentive to buy a Mac the next time you purchase a computer if you find yourself forced into a different OS anyway.
Apple has been offering solutions to run Windows apps for over two decades. First they bundled SoftWindows with early PPC Macs, then they offered hardware Intel daughtercards and they have been bundling Boot Camp since shortly after the Intel Macs were introduced.
There is very little important software outside of iOS development software that is Mac only. People who care about backwards compatibility would never buy Macs.
There is very little important software outside of iOS development software that is Mac only. People who care about backwards compatibility would never buy Macs.
> There is very little important software outside of iOS development software that is Mac only.
So true; it feels like every Mac app is Electron these days.
So true; it feels like every Mac app is Electron these days.
> It also relies on a new feature of macOS Catalina to allow the creation of 32-bit code segments in a 64-bit process.
How was this never brought up during all the "Catalina killed 32-bit" pitchforkings? Seems like a very important point, that has enabled the ability to emulate 32-bit apps.
How was this never brought up during all the "Catalina killed 32-bit" pitchforkings? Seems like a very important point, that has enabled the ability to emulate 32-bit apps.
AFAICT, this won't let people run existing 32 bit apps out of the box. Instead, it enables the creation of 32 bit stub libraries that can call their 64 bit counterparts in behalf of the application. Although it's possible in theory to run existing 32 bit apps by creating stub libraries for 32 bit APIs, it's likely to require so much effort that I doubt this is going to happen.
It’s gated by an undocumented entitlement.
I don't know how to mentally parse this sentence. (Not snark; stumped.)
"entitlements" are OSX Catalina's new(ish?) permission grants that applications need in order to access certain features like JIT or specific syscalls.
The entitlement needed for this feature to work is undocumented.
See here: https://developer.apple.com/documentation/bundleresources/en...
The entitlement needed for this feature to work is undocumented.
See here: https://developer.apple.com/documentation/bundleresources/en...
Entitlements aren't new, they existed since ages (OS X 10.11 already used them quite a bit).
Catalina makes them all-but-required, though, even for non-store apps, between SIP (System Integrity Protection) and the on-by-default enforcement of notarization.
On previous versions of macOS, regular developers could mostly avoid needing to touch them by just not being a store app.
iOS developers have had to think about them since the early days.
On previous versions of macOS, regular developers could mostly avoid needing to touch them by just not being a store app.
iOS developers have had to think about them since the early days.
Sandboxed applications relied on them even before that.
From the article:
> the big thing that Catalina provides that enables this all to work is the ability to create 32-bit code segments in a 64-bit process. For that, they enabled the use of i386_set_ldt() in 64-bit processes. The big caveat though, is that this functionality is restricted by System Integrity Protection (SIP). For now, your best bet to get this working for yourself is to disable SIP. (CrossOver doesn't require that, but the mechanism by which we accomplish that is in flux internally to Apple. When it settles down, I'll update this thread.)
> the big thing that Catalina provides that enables this all to work is the ability to create 32-bit code segments in a 64-bit process. For that, they enabled the use of i386_set_ldt() in 64-bit processes. The big caveat though, is that this functionality is restricted by System Integrity Protection (SIP). For now, your best bet to get this working for yourself is to disable SIP. (CrossOver doesn't require that, but the mechanism by which we accomplish that is in flux internally to Apple. When it settles down, I'll update this thread.)
Okay that’s just impressive. I was wondering how they would adapt for 32bit support on Catalina.
> It also relies on a new feature of macOS Catalina to allow the creation of 32-bit code segments in a 64-bit process
Is this roughly equivalent to MAP_32BIT on Linux?
http://man7.org/linux/man-pages/man2/mmap.2.html
Is this roughly equivalent to MAP_32BIT on Linux?
http://man7.org/linux/man-pages/man2/mmap.2.html
No, it is like modify_ldt on Linux.
http://man7.org/linux/man-pages/man2/modify_ldt.2.html
http://man7.org/linux/man-pages/man2/modify_ldt.2.html
Why OpenBSD/amd64 will not, and never has supported 32-bit binary compatibility on 64-bit.
https://marc.info/?l=openbsd-misc&m=148926149318522
https://marc.info/?l=openbsd-misc&m=148926149318522
>> ...coordinated using mainly nothing but email and IRC for communication.
I wonder what other projects (on a scale larger than your typical side hustle projects) are coordinated via IM chat or email?
On the surface, the Linux kernel coordination seems to be coordinated like this, but I am not 100% sure.
I wonder what other projects (on a scale larger than your typical side hustle projects) are coordinated via IM chat or email?
On the surface, the Linux kernel coordination seems to be coordinated like this, but I am not 100% sure.
Every open source project that’s reasonable enough not to hide all their communications in proprietary silos like Slack and Discord.
Jayflux, most open source IRC channels are logged on webservers. Those logs are usually also searchable on Google, and you don't need to sign in to view them. Unlike Slack etc
Ok I’ll bite..
Seeing that both slack and discord save logs from the beginning (which irc doesn’t), isn’t communication less hidden if anything? It’s far easier for someone new to play catch up.
There’s a reason large open source projects moved to these (React, Rust, etc).
Seeing that both slack and discord save logs from the beginning (which irc doesn’t), isn’t communication less hidden if anything? It’s far easier for someone new to play catch up.
There’s a reason large open source projects moved to these (React, Rust, etc).
As jononor already said they are usually logged to a public location. And even if they are not they are logged in plain text on each client usually.
In Slack the logs are also not searchable if you above a certain threshold (10k lines or something) if you don’t pay. Slack is prohibitively expensive if you have a lot of users and not really made for such a non-company use case.
In Slack the logs are also not searchable if you above a certain threshold (10k lines or something) if you don’t pay. Slack is prohibitively expensive if you have a lot of users and not really made for such a non-company use case.
Open source projects typically cannot afford to pay for slack, which makes all but the most recent logs unsearchable. I've found this in quite a few open source groups and it means the same questions get asked over and over again and its incredibly wasteful and irritating IMHO.
These open source groups could surely use a chatbot to log the chats to some place for archival and make the archive searchable, can't they?
By the way, I find IRC/Slack good for real-time support. By nature of being real-time support, some questions get repeated over and over again. The repeition is typically mitigated by adding trivia bots to the channel that can provide answers to frequently asked questions.
The best solution I have seen for archived solutions and to avoid repetition are Stack Overflow (encourage users to post questions on SO with relevant tag) and mailing list with a mailing list archive.
By the way, I find IRC/Slack good for real-time support. By nature of being real-time support, some questions get repeated over and over again. The repeition is typically mitigated by adding trivia bots to the channel that can provide answers to frequently asked questions.
The best solution I have seen for archived solutions and to avoid repetition are Stack Overflow (encourage users to post questions on SO with relevant tag) and mailing list with a mailing list archive.
Are there any Slack chatbots that do that kind of logging and archiving? When I searched a couple years ago, I found several projects... and none of them worked except one (SlackArchive.io, I think), which worked for another couple months after I found it then died with, IIRC, communication from its operators that suggested Slack was cracking down on bots that were being used for this purpose. (Which is not unexpected.)
Slack and Discord may have logs but you have to download a massive blob of proprietary software, register and agree to some ToS to access them. Those logs are everything but public.
> isn’t communication less hidden if anything?
Not everyone uses IRC (but it has archives). Email (and its archives) are a thing, too.
Given you can read all the development of the Linux kernel since almost the beginning (and they don't use chat IIRC), I don't think you are correct.
> There’s a reason large open source projects moved to these (React, Rust, etc).
No, there is no reason. They are newer projects with younger people and they just picked something more modern, based on a web browser.
If there was truly a reason, the kernel and other projects would have moved, too.
You can argue, of course, the pros and cons of each alternative.
Not everyone uses IRC (but it has archives). Email (and its archives) are a thing, too.
Given you can read all the development of the Linux kernel since almost the beginning (and they don't use chat IIRC), I don't think you are correct.
> There’s a reason large open source projects moved to these (React, Rust, etc).
No, there is no reason. They are newer projects with younger people and they just picked something more modern, based on a web browser.
If there was truly a reason, the kernel and other projects would have moved, too.
You can argue, of course, the pros and cons of each alternative.
No Rust did actually move (its 'official') channel off IRC.
I believe it was sort of catalysed by Mozilla shutting down its IRC servers, but presumably it was already an issue being discussed, and that was just the final nail.
I believe it was sort of catalysed by Mozilla shutting down its IRC servers, but presumably it was already an issue being discussed, and that was just the final nail.
And since that happened, I've stopped engaging with the community at large. There are people who disagree, but I personally do not want to waste stupid amounts of memory to do ephemeral messaging. And their gatekeeping bot is stupid.
All of the replies to your comment seem to be pointing out that IRC can be logged, but they're missing the point. You shouldn't play catch-up on IRC. Any useful information to persist should flow into the docs or onto the mailing list. On IRC, no one is expected to stay abreast of discussions they were absent for.
Long-term documentation is not the reason logs are useful. Asynchronous communication is the reason logs are useful.
That is, you can ping people who are offline, or with a flaky network connection (e.g. mobile, where you can't keep a consistent TCP stream open), and they can still see your message and a bit of context when they get back.
That is, you can ping people who are offline, or with a flaky network connection (e.g. mobile, where you can't keep a consistent TCP stream open), and they can still see your message and a bit of context when they get back.
Long term documentation should be not be in any emails or IRC logs. It should be properly documented as a formal documentation. But that is different to coordinating a team.
When I was at Canonical back in 2007-2008, we were mostly communicating using email and IRC. I had to adapt but ended up finding it very productive.
Basically every open source project that isnt "Group of devs at the same company" works like this.
Open source projects are likely the largest user of mailing lists.
Open source projects are likely the largest user of mailing lists.
I'd argue it works for devs at the same company quite well, but having asynchronous communication is counter to your average business persons desire to lock you in a room for an hour and make you make a decision.
PyPy works primarily on #pypy, with yearly sprints and additional coordination on the PyPy-dev mailing list
We detached this subthread from https://news.ycombinator.com/item?id=21788357.
The kernel doesn't actually use IRC for coordination. There's a channel but technical discussion is rare.
Many components of Firefox are.
[deleted]
Everything from thunking layers to calling conventions to inline assembly in the Wine codebase had to be redesigned for this release of Wine; an absolutely massive proposition. Ideas such as dynamic binary translation and running Win32 executables in the MacOS hypervisor framework were considered, and some ideas I tried while hacking Wine gave me insight into other projects I hack on such as Qemu and LLVM.
In short; props to everyone who worked on this! It was a long time in the process!