I'd like to take a moment to be grateful for the small graces of the current copyright climate that allow projects like this to exist. If the parameters of a few lines of US Code were slightly tweaked, or a few court rulings different, we'd simply not have this amazing feat of interoperability available.

It's really an amazing thing that we're able to foster projects like this in the open, and we should be careful to preserve those freedoms.

Yes, and it makes you wonder what other amazing things we're missing out on, but for some quirk of law or successful lobbying.

> Yes, and it makes you wonder what other amazing things we're missing out on, but for some quirk of law or successful lobbying.

A few simplified examples from off the top of my head:

pre ww2 most employers didn't provide insurance. during ww2 healthcare was offered as a perk of the job back in the day because wage freezes caused by world war 2 inflation concerns. you can say that because of hitler that it is the way it is now and now there is a huge political donation machinery to prevent single payer health care.(downsides being that if you are rich you can get really good healthcare for less than you'd pay into a single payer system and there are millions of jobs related to the bureaucracy of being in the middle of provider and patient)

china has very lax copyright/patent enforcement and as such places like shenzen's markets where you can find thousands of little electronic bits and pieces and clones are rampant with a very large maker movement. (of course there is a downside to this in that the capitalists don't get to benefit as much on whatever innovation was there originally)

regulatory capture on other industries are also from that lobbying.

I find it interesting how large the maker movement is in China despite the very lax copyright. It simply has no or net positive effect, it would seem. I know I'm oversimplifying, but I think the general argument against relaxing copyright protections, at least the most common I've heard, is precisely that.

Because they are lax on foreign copyrights and not domestic ones?

Do you have any evidence for that claim?

It's not a claim but a rhetorical question, hence the question mark...

A rhetorical question is a question asked to make a point, rather than get an answer.[1] A point, aka a claim here.

But maybe you meant a non-rhetorical question. In which case, it would be clearer if you started it with a "Maybe" - if your intent was to genuinely ask it as a question.

[1] https://www.bbc.co.uk/bitesize/topics/zmfc7ty/articles/z7dyv...

The downside is that whatever you can find to buy is ripped off from whoever invented it, usually neglecting rudiments of quality control.

Has this ever been tested? If Linux can decide license requirements for modules that implement their apis, I’m not so sure Microsoft couldn’t block Wine if they really wanted.

The license in Linux case is for distributing Linux (and the module). You can create modules with whatever license you'd like if you're not distributing your work. In Wine's case you're not distributing Windows so it's not the same.

A more similar case would be Oracle vs. Google over the Java API.

I thought some of the modules are checked for licence field prior to loading them. You could modify that if you keep the whole internal

I recently used Wine to run Office 97 on Debian, just for old time's sake.

I ended up liking it so much that I now use it for my word processing and spreadsheet tasks. This classic version is feature complete to me. Wine ensures it lives on, long past its support date and on an alien operating system.

And clippit says hello!

Screenshot for the curious: https://imgur.com/a/GmVUAfC

It shows Word 97 on Linux editing a lengthy docx converted by LibreOffice. Images, text boxes and arrows all came back to 1997 unscathed.

I do the same with Office 2003! There is even a compability pack for docx/xlsx files so it's really good

Edit: If anyone needs it. Looks like MS removed the original download but still available from CNET https://download.cnet.com/Microsoft-Office-Compatibility-Pac...

My IT department still uses a home-grown work ticketing system built in Access 97. The leadership in the department built it custom to their wants in the 90s and, just like you, it's feature-complete-ish. Pain in the butt for newer employees like me.

Please don't tell them that it works in Wine. It needs to die.

But then all computers in your company can now move to Linux! Surely they'll love it when you pitch this news to them.

An interesting question: which Office version is the best assuming one does not want a modern version with the ribbon interface (so 2007+ is out)?

Looking at wikipedia new feature list, most features following 97 aren't very compelling for a single user: "HTML support"? "Collaboration features"? "Customized XML schemas"? Meh.

However, Office XP IMHO has a few minor improvements (minor UI refresh, print preview in PowerPoint, bulleted lists in Word, better password protection in general and docx/xlsx support via the Open XML Compatibility Pack though that's common for every version from Office 2000 to 2003) that make it worthwhile over 97.

I think you should go with Office 2010 even though you dislike the ribbon.

Office 2003 is a delight to use, but any version prior to 2007 will lack support by default to docx, xlsx and pptx formats, which are the current file formats and the ones someone would share with you in the "real world".

Using an older version, even if you install the compatibility pack as someone suggested in another comment, you will experience many issues -- especially in Excel, which was heavily modified (e.g. rows increased from 2^16 to 2^20, new color model replacing the old palette of 16 user-defined colors, new functions such as SUMIFS and COUNTIFS, new implementations for sorting, filtering, conditional formatting etc).

Excel 2010 is almost like 2007, but with many tweaks, corrected statistical functions (they were notoriously unreliable in previous versions) and with improvements to charts which are still almost 100% compatible with the latest version. You should have no problems at all creating and editing documents between Excel 2010 and the most recent version in either direction.

Being an older version of Office, it's also very responsive even on low-end machines -- just be sure to install the 64 bits version.

As for the ribbon, remember that you can double click any tab (for instance, "Data") to automatically hide the menu. You can also customize each and every button on it (right button, "Customize the ribbon").

2003 is best option for you then - it also contains the last classic office file format implementations, so highest chances you can convert files with minimal hassle from newer versions.

So interesting… does it work well with modern word documents? I don’t expect it to run docx but somehow I think it might be better than open office in some aspects

It fares quite well, actually. Here's a screenshot:

https://imgur.com/a/GmVUAfC

I converted my dissertation from Docx to Doc using LibreOffice Writer. It opened in Word 97 almost identically (some page breaks notwithstanding). In my dissertation I had a screenshot with some text boxes and arrows floating over it. Good old Word 97 rendered it perfectly, position, formatting, the works. To complete the picture, after opening my dissertation, Clippit looks suitably bored.

And on Office97 running Docx, funny you mention that. While there is no official way, there are those in this thread who have got the MS FileFormatConverters to work:

https://msfn.org/board/topic/133124-ms-office-2007-compatibi...

When I have a spare weekend, I'm going to try this in my Wine'd setup and see how far I get. The results will become a blog post.

> I converted my dissertation from Docx to Doc using LibreOffice Writer. It opened in Word 97 almost identically (some page breaks notwithstanding). In my dissertation I had a screenshot with some text boxes and arrows floating over it. Good old Word 97 rendered it perfectly, position, formatting, the works. To complete the picture, after opening my dissertation, Clippit looks suitably bored.

I bet if you used Office to convert Docx to Doc, Word 97 would import it without problems. LibreOffice seems to make lossy conversions between formats.

I've never thought to try this.

Now I have to try this.

You're welcome to join!

Installation requires the 32 bit Wine runtime, which will require pulling in your distro's 32 bit libs. After that set

   export WINEARCH="win32"

in your env, just run setup and all is golden.

It is worth noting that Office 97 + all deps required for 32 bit Wine is still a smaller installation size than any recent Office.

Interestingly, this announcement makes it sound like you might not even need 32-bit libraries anymore:

- The 64-bit Windows-on-Windows (WoW64) architecture is implemented, and supports running a 32-bit Windows application inside a 64-bit Unix host process, using thunks to map 32-bit NT system calls to the 64-bit NTDLL.

- WoW64 thunks are implemented for most Unix libraries, enabling a 32-bit PE module to call a 64-bit Unix library. Once the remaining modules are converted to PE, this will make it possible to run 32-bit applications without installing 32-bit Unix libraries.

I wonder how that will work on M1 macs. Right now, trying to run any 32-bit executable with Wine 6 is being met with "bad CPU type in executable".

CrossOver’s Wine builds have wine32on64 to run x86_32 programs using Rosetta 2 on M1 macs.

Available at https://github.com/Gcenx/homebrew-wine if you want to use a free build for example.

Soon you'll write code under DOS Turbo Pascal 5.5

I've tested old Delphi versions and they were a joy to use under WINE.

For the more adventurous, years ago there was a"special" version of Delphi 7 around called like "Delphi 7.2 second edition" which essentially was to plain Delphi what the "ultra lite" versions of the OS were to XP back then: the author removed all the cruft, applied lots of optimizations here and there making the compiler a lot faster and the entire package much smaller. If memory serves, the entire installation file was less than 50MB. It literally flied on old machines. Was it legal? Definitely not, but it was probably safe; when installed on Windows it didn't trigger any AV.

What modern MS Office features are missing from '97 but still useful?

I'm thinking you won't be able to write formulas using Latex. There's also a 32-bit limit for the amount of memory a program can use.

Crash recovery

OpenOffice.org and LibreOffice always used to do this much better than Microsoft, but my understanding is that Microsoft has made more of an effort more recently.

It is also useful if the program gets unexpectedly closed (for example by a reboot).

I’m not so sure. I lost a day of school work in November because Word crashed and I wasn’t syncing the file to the cloud. It seems you need to use the cloud service for decent crash recovery.

My experience is that every Enterprise IT department deploys their Office installs / workstations in such a way as to render Office's crash recovery useless.

I usually save every time I make a major change (around an hour)

Office 97 has autosave, which works quite nice, I'd say better than current Office but worse then Open/LibreOffice.

Works quiet nice until it crashes and corrupts both the autosave file and your working document. First thing i do after i install office is disable autosave. Got bitten badly.

I think the worst would be .doc extensions instead of .docx

Other than that, give me WP5.1 baby

IMO, .doc might be the second worst format ever invented (second to PDF). It is a proprietary, binary only format for storing text documents. Who thought that was a good idea?

It's an artifact of a time when RAM was extremely expensive and CPUs were slow. Dumping the in-memory binary representation to a disk was apparently the logical choice at the time.

Too bad SQLite didn't exist at the time. It would be a pretty good candidate for something like that without eating bogs of memory for large documents.

To be fair to the Office team of the day, when your company also develops the compiler and can guarantee the safety of writing and loading raw structures under specific constraints (even in ways that violate programming language standards), it's not too bad of an idea. Not that it's the greatest, as even then there were certainly better ways of doing it, but the landscape of serialization wasn't as nice as it is now.

SQLite would not be a good choice.

DOC file format, combined with OLE containers, was designed at least partly to deal with common practice of keeping documents on floppies, and to make saving documents as speedy as possible.

This meant a combination of pseudo filesystem (OLE containers can be summarised as a variation of FAT filesystem) and blittable data structures. This way when you saved an updated version of the document, Word would only extend the file with new changes, minimizing amount of I/O necessary.

Another aspect to this was that DOC was not supposed to be interchange file format - that's a role that was supposed to belong to RTF. Which was much easier to parse and had formal, published specification instead of memory dumps of internal data structures. However it took a more resources to update such file, so RTF and DOC were kept in sync when it came to capabilities all the way to Office 2003 - everything you could do in DOC, you could do in RTF, and vice-versa.

Of course, practice quickly went in different direction and most people only think of RTF as the simpler sibling of DOC, because WordPad on Windows used it.

Quick and easy for the devs too I bet.

Not quick nor easy at all - it was an optimization for end users.

PDF is not for making documents with, it's for making bundled printouts that almost universally are printed right on most printers.

PDF is possibly the most successful technology in computing history.

I cant judge .doc on its technical merits, but its closed nature is really something.

Rumor is that, in the end, even MS didn’t understand the format?

Photoshop is said to be on par. Similar reasons behind the 'format' .. or dump.

Why is pdf bad in your opinion?

It's a 2000 page spec that links to other specs (eg JPEG, PNG). It is a turing complete document format that can run arbitrary code without a sandbox. It is a mix of a binary and text format (some opcodes are in binary, some in text which just why?). All in all, it is a format designed to be incredibly hard to implement so people just give up and pay adobe.

Other than some stupid feature of it (like some of the ones you mentioned, maybe also forms), I really don’t think it is too hard to implement - there are plenty of open-source pdf reader libraries.

From what I've seen, most of the libraries out there are some mix of incomplete and slow. From my testing (from a few years ago), most of them supported about 80% of the documents you would see in the wild. Good support for FDF (form fillable PDF) was really bad pretty much across the board.

20 years ago, fresh out of uni, my first job was working on some delphi that modified pdfs.

With no libraries! That was painful.

Plenty as in poppler, mupdf and pdfium? Are there others?

There are open-source libraries as well for e.g. Java, C# and I guess a bunch of other languages.

Office 97 is probably missing support for modern Unicode (i.e. astral planes). Apparently Office 97 was the first version to support Unicode at all, but I bet it's BMP only.

I also highly suspect Office 97 has no support for modern OpenType features, so your text may look worse, depending on the font.

I'm not sure if it's considered a feature, but high DPI support in text editors/viewers is such a game changer for me that I can never go back.

Apart from what others have already written, there is little support for multimedia formats. So, if you want to embed some videos in a Powerpoint presentation, expect troubles…

It looks like you're writing a letter.

Would you like help?

I know you are being serious but the joke was: "It looks like you're writing a suicide letter.

Would you like help?"

Same, but with Office 2007. I'm getting ready to upgrade to Office 2010 mostly for 64 bit support. Any suggestion to run it best on wine64?

Alternatively, how to migrate an old wine32 bottle to wine7 amd64?

I thought its name was clippy?

His public persona, yes. We're close enough that I'm permitted to use his real name.

Not officially, but "Clippy" is way more common https://en.wikipedia.org/wiki/Office_Assistant

It's amazing to think that the technology behind Clippy is the foundation for all of Microsoft's AI and ML work.

I mean it probably isn't, but it's still amazing to think it.

Merlin, the puppy and the kitten in Office were based on Microsoft Agent: https://en.wikipedia.org/wiki/Microsoft_Agent

Yes it is. It was the first crap feature enabled by default using dark patterns when you try to disable it.

How do you even get a legit copy of Office 97 these days?

Independent of copyright term reductions, I think you really should have to continue to activiely distribute something in order to retain copyright. Abandonware should be equivalent with public domain.

eBay, Craigslist, etc.

How well does it run?

Excel, Word and PowerPoint run as well as they did on Windows. All the main functionality is very stable. Wine even integrated the icons and mime-types into my DE.

It is only very occasionally I hit any critical error. It has only happened when trying something obscure, like "Microsoft Maps for Excel".

I haven't tried Outlook 97 yet.

But poor old Access won't even get off the ground. I'm guessing due to some ODBC driver too stodgy to have a sip of Wine.

Interesting. My main use case for using Word would be for my CV. Since I don't want it to render a single bit different than on a recruiting manager's screen. Unfortunately PDF still seems to be a bit of a disadvantage in some cases.

This doesn't quite make sense to me. Sending your Resume in .docx is kind of a terrible idea, and I've seen countless people running mainstream Windows version getting bitten by this. On top this, in my experience it's *much* easier for me as an interviewer to review your resume in PDF rather than docx (even if I have access to MS Word or Google Docs). I have never seen any company or recruiter (in the US) who prefers docx but I've seen multiple companies (including my own) that prefer PDF.

So, someone going out of their way to type their resume in wine word, only for it to be a scrambled mess... I would strongly recommend you not to do this. If you're emailing your resume and you absolutely want to go ahead with your plan, please consider adding both the pdf and docx. Good luck!

It is actually not for employment, but as I work as consultant / contractor I have these agencies between me and possible customers. They enjoy to edit out any contact information from CVs to act as middlemen. It sucks but does not reflect on the actual assignment in the end.

The idea to send it in both versions is actually very good. Thank you!

Ah I see. Never worked as a consultant/contractor so I wouldn't know!

I have never heard anyone have problems with a PDF CV. If that's a disqualification reason... I don't know.

This is speaking of IT of course; if you are talking to a small business doing woodworking or whatever, all bets are off on what tech they can and cannot handle. I'd still bet on PDF more than doc(x), though, since maybe they don't have an expensive Word license but PDF should render in browsers.

There are still corners of the world where docx is the One True Format, and PDFs make you seem like the weirdo. I can easily imagine it being too different/difficult and a candidate being rejected from the enormous pile for that. The Internet has made it far more common to get outsized responses; eg 800 applicants for 3 positions, with no easy way to sort through them all.

It is actually not for employment, but as I work as consultant / contractor I have these agencies between me and possible customers. They enjoy to edit out any contact information from CVs to act as middlemen. It sucks but does not reflect on the actual assignment in the end.

Oh, okay yeah if they want to make edits, then giving them rendered output is indeed not the nice thing to do.

If you install modern fonts and get busy with the drawing tools, you can produce a modern styled CV. I would say the chances are good if you made a modern one and saved it as a .doc it would open identically in modern Word. (Though, I have already some ideas for a blog post on this, I might try this scenario too and see what modern Word makes of it!)

I actually used Word 97 to write a report for university. I switched Arial for Calibri and they were none the wiser.

Outlook 97 was the last decent version (and I think the last version to fully support Lookout, whose ability to index public folders before people thought ACLs were necessary resulted in some interesting discoveries).

Then again I have (reasonably) positive memories of MS-Mail. The version of desktop Outlook I have to use (2016?) is a horrible buggy mess.

I love to see these updates. Wine has been so useful here that I started buying some old Windows games from Gog even though they don't specify Linux compatibility. I also went back to a vendor I used to use for Windows software and bought their latest version once I found it worked perfectly for my purposes in Wine. So, huge thanks to the Wine developers.

Also, somebody has packaged Wine for Haiku OS, and it runs inside of virtualized Debian so that users can play with Windows apps. I thought that was a pretty neat idea.

As someone acquainted with linux gaming, the general rule of thumb is that anything without anticheat works.

Thanks to Valves work, a bunch of games with anticheat are starting to work as well.

I use Wine to run Photoshop CC 2018 on Ubuntu LTS and my life would be very different if that were not possible.

For those curious, no I don’t use a licensed version, but I would if that were possible. Maybe it is with Wine 7.0. I will give it a try. Both Photoshop CC 2018 and Illustrator CC 2019 run flawlessly with hires monitor support and all.

I dislike how Adobe forces you to have the latest version of their software, even if you don't care about not having their support, but I think some people could could sue them for not having that support and some other legal issues.

I know this because I have to help a friend to update from Windows 7 to Windows 10 due to this. She know have a relative slower OS, a slower Photoshop version, and no benefit to the work she do.

I have seven versions of Illustrator sitting on my computer. The last five work just fine if I try to run them (albiet with a bunch of "this is from an unknown developer" errors from OSX on the plugins for 2018). OSX says 2014 and 2015 "may be damaged or incomplete".

There might be some deliberate breakage of very old versions, I dunno, but you can definitely keep on working with old versions for several years. Which is a good thing given that the .0 version of a new release has a 25% chance of being completely unusable due to either a killer bug or a feature change that breaks your workflow until enough people scream on the bug/feature request forum for them to add a fix/switch in the .1 version.

I think CS2-5 might be the golden era for adobe products that won't retroactively break. I know a purchased CS5 still works absolutely seamlessly on my 2010 osx, and I've ahem played around with CS2 in a different context experiencing the same.

Rule of thumb I'd go for is pre-CC.

Wine is one of those projects that really blew my mind when I first tried it out, and made Linux a fascinating OS to use. Hooking it up with binfmt_misc can make running Windows binaries on Linux a seamless process. It was also great on macOS.

One of the coolest things about Wine is Winelib. If you compile against it, you can create a binary that will run natively on Windows, and it will run in Wine on any Wine-enabled platform like Linux, BSD, macOS or HaikuOS. Instead of targeting Windows and hoping the resulting binary will work on Wine, you get Windows and multi-platform Wine support for free.

> Once the remaining modules are converted to PE, this will make it possible to run 32-bit applications without installing 32-bit Unix libraries.

That sounds really amazing, I can't wait. That will really simplify using 32bit windows programs on a 64 bit OS.

Crossover has had this feature for awhile[0]

0: https://www.codeweavers.com/blog/jwhite/2019/12/10/celebrati...

It is nice to see the changes being moved to the open source version, I appreciate the fact that they do let non-paying users use those features.

Agreed, this reduces the need to keep 32-bit libraries around, though there are still native games that need that. May be something similar can be done for ELF libraries? That would be really cool.

I have a patch that adds AF_UNIX support (added in Windows 10). It needs help to get it upstream. https://www.winehq.org/pipermail/wine-devel/2021-May/187049....

Have you opened up an issue on Wine's bug tracker? Looks like no one is biting at your mailing list submissions.

Nice, maybe worth having a test in the test suite ?

As another commenter wrote opening a bug is a good idea, mention a program this helps get working too.

I can enjoy playing Cyberpunk 2077 on Linux thanks to Wine, vkd3d-proton and Mesa projects. Kudos to all involved developers!

As for PE updates, looking forward to these to be rebased: https://github.com/wine-staging/wine-staging/tree/master/pat...

Switch to PE broke that.

Wow, an incredible amount of work/updates in this version. So glad to see a project like this continue moving forward in significant ways and I hope that these improvements bode well for things like Proton

I think it might be the other way around, Valve(proton) improves wine. Since they(valve) started working on game compatibility both wine, and dxvk has gotten a lot of love. Which continues to show that "real" enterprise investments are needed to advance some complex software, be it open source or not. Everything can't be done on a hobbyist basis.

As far as I know, Wine has not primarily been a hobbyist project for about 15 years, with the bulk of development being done by CodeWeavers, which uses it as the basis for their CrossOver product. I don't believe any of that has substantially changed with the advent of Proton, though I assume that Valve is paying CodeWeavers to also pay attention to Proton issues.

You're probably right, I don't know for sure but I believe Valve has employees working on these projects too, considering their investment in SteamDeck.

> I believe Valve has employees working on these projects too

Very few, actually. Most of the actual work on these projects is contracted out. You can view the git logs, not many @valvesoftware.com addresses.

Also worth being aware of https://www.codeweavers.com/crossover (wine based) Fairly cheap and great for not having to have a windows machine at work!

I'm hoping that I'm correctly interpreting the WoW64 portion of the notes as meaning that I could run a 32-bit x86 Windows binary using the 64-bit Wine on ARM. I don't have a common need for this but I've had a couple of cases where I needed to test compatibility with something ancient and it would have been great to be able to install something in my development environment. In one of the cases, it was a 64-bit executable with a 32-bit installer so the actual program worked as long as you could copy a previous install.

You can't do that yet, but it is a step in that direction. The general idea is that Wine is getting organized on two layers: the PE .dll libraries, which are similar to a Windows userspace, and the Unix libraries, which act as a sort of "kernel". The interface between the two is standardized and is kind of close to a system call interface (we actually call those "syscalls", even though what I can "kernel" is still a bunch of userspace .so libraries, so the processor is not really switched to kernel mode, and there is no hard enforcement of boundaries; also, many of these syscalls are much higher level than what you'd usually expect from a real kernel-userspace boundary).

Once all modules are converted (there are still a few missing, unfortunately the hard ones, but people are working on those), the PE world interact with the external system only through this "syscall" interface. The Unix world is required to be compiled for the external system's architecture, but the PE world can be whatever you want, provided that you do the appropriate things at the syscall interface.

For example, you can have 32 PE libraries and 64 bit Unix libraries, and at the syscall interface you switch the processor back and forth between 32 and 64. Or you can have x86 PE and ARM (or whatever) Unix, and you enable/disable an emulator at syscalls.

Wine Is Not an Emulator, so I doubt it will be able to run x86 apps on ARM.

This is a semantics debate, but it kind of is an emulator. Instead of emulating a CPU, it emulates the Windows API. That's obviously a major difference: One is inherently slower, while the other is inherently more complicated.

WINE originally stood for "Windows Emulator", but for trademark reasons it was changed to "Wine Is Not An Emulator". That's giving you some mixed messages now, isn't it? [edit] I just checked Wikipedia, and that's not true -- the name wasn't changed due to a trademark problem, it was changed due to a genuine confusion about what the term "emulator" meant.

It implements the Windows API.

And the Windows API is defined as "whatever Windows does", which Wine emulates.

> - The new Apple Silicon Macs are supported, including running x86-64 binaries under Rosetta 2.

Depends which ARM :)

Apple Silicon has special support for running ARM code with the "Total Store Order" memory model of x86.

JIT-compiling emulators for other ARM processors otherwise need to be stuff the code full of memory fence instructions to be able to utilise multiple cores properly. Optimising those away can be hard.

Not really though, it's just another layer which isn't wine. They might put effort in to help Rosetta translate, but wine is not an emulator.

I think some bits got added from the point where they got Wine working on OSX PPC back in the day.

I'm aware of what the acronym originally meant, but this was listed as working in the 6.x series for 64-bit x86 apps.

You can setup binfmt_misc to run x86 Windows binaries with Wine and Qemu on other architectures like ARM.

That probably won't work, WoW64 is running x86-64 on x86-32. You can combine Wine with QEMU to run x86-32 on AArch64 though.

That’s how I interpreted it as well for running 32-bit apps on 64-bit Host.

I'm curious to see if this means I'll be able to use Wine again on MacOS post-Catalina (10.15) when Apple removed 32-bit support. I'm still on an Intel-based machine back from 2019 so I'm hoping this means support in the near future when a new version is available on Homebrew.

Then again I might be interpreting the release notes incorrectly and getting my hopes up for nothing.

The Crossover version works well on post-Catalina systems. You can just buy it or... compile their code :) There is a gcenx build available here: https://github.com/Gcenx/homebrew-wine .

IIRC Crossover handles this already, and there's a version of Wine compiled from the Crossover code floating around.

Wine 6 works on M1 macs with 64-bit binaries.

I'm using it for Mikrotik Winbox and it works wonderfully. (Though Mikrotik cares for Wine compatibility).

I use Wine for one thing: running MusicBee. It's a pain in the ass to get it working 100%. Every time I've tried to upgrade past wine 4.x it completely breaks my MusicBee wine prefix, so I've locked the version and will never upgrade. Ultimate goal is to wait until any native Linux music player is even 10% as good as MusicBee.

MusicBee was one thing I looked over in my switch to Linux a couple months ago. In my head, I could simply find any other music player for Linux and be on with my life. But I found that MusicBee had so much ancillary functions that had made their way into my music management flows over the years that were lacking in other players. I still haven't bothered to find another player, but I have been working on creating new flows using beets, which is probably a better approach as it separates the concerns of managing and playing my music.

I used to have this problem, I ended up stopping using MusicBee. I found Sayonara to be a near 100% replacement. https://sayonara-player.com/

I know I tried it and uninstalled it. Gonna try it again and let you know why I'm uninstalling it again (because I forget)

Which features do you desire? What is your ideal music player?

1. Main music browser pane should be in column format (think: "excel spreadsheet" with configurable columns of metadata), with a search bar that filters on any visible column or advanced metadata search.

2. Separate "Now playing" pane so I can browse in the main page without affecting what is currently playing (lots of players break this). It's basically a separate, anonymous playlist.

3. Support for custom id3 tags. These have been around for decades but only have limited support. Some players do a half assed job, others don't bother at all, some don't even support the "comment" field. MusicBee let's me define tags and use them as columns in the music browser, Now Playing view, smart playlists, searches etc.

That's it. Decent playlist management would be great but I don't find MusicBee particularly outstanding here either. What I'd like is the ability to tag my playlists with the year, moods and comments - like virtual compilation albums.

I don't use my music player for stupid visualisations. I don't care about lyrics or album art. It's 100% about finding music and creating a play queue. If I like the queue I can save it as a new playlist. That's it.

Quodlibet isnt exactly a 1:1 replacement, but Im very happy with it. You might give it a try.

Tried it. Didn't like the ui. More importantly it doesn't let me browse my extended id3 tags so it's basically useless to me.

Spotify runs fine on Linux and you'll free up a ton of disk space!

The economics don't work for me. I already have a large collection. Disk space is cheap (practically free). Spotify costs money every month to play music I already own. Spotify also lacks certain songs (or versions of songs). If I stop paying for Spotify I keep nothing, but if I stop buying albums I keep everything I already own. Last time I checked, it didn't allow you to tag tracks. That may have changed, but I doubt it.

> The Clang compiler in MSVC mode is supported.

This is very good, because it means cross compiling and testing Windows builds from Unix just got a lot better.

So as a Wine end-user, it looks like this release means no more having to have multiple wineprefixes to support both 32/64 bit applications, and also no more need to ensure libraries like libpng zlib etc are installed, either 32 or 64 bits? That seems quite nice.

> So as a Wine end-user, it looks like this release means no more having to have multiple wineprefixes to support both 32/64 bit applications

WoW64 prefixes have been possible for a long time.

> and also no more need to ensure libraries like libpng zlib etc are installed, either 32 or 64 bits? That seems quite nice

That seems to be the plan, but according the release notes there are still some native 32-bit libraries that will be needed.

I just got into astrophotography and Wine has been a blessing to have. There are a lot of tools that are wintel only and being able to just run them without going through the hassle of building a vm has been fantastic.

Do the apps you run talk to hardware at all? I haven't run into a case where I've needed to run Windows apps to communicate with hardware, so I'm interested in whether that's something Wine has already tackled well.

Yes, almost exclusively low speed serial comms (ASCOM to the mount) and it generally has been flawless.

The only lesson learned is that there is a wine config file that maps serial ports out of the box and I had to nuke that config to pick up my serial port (it was on /dev/ttyUSB0 vs/dev/ttySx)

Is it possible to run Corel Painter on Linux with a recent version of Wine ? The database says "Garbage" https://appdb.winehq.org/objectManager.php?sClass=applicatio..., but the versions don't seem up to date...

Well I just tried Painter 11 and the installer hang. Tried Amazon Games and the installer crashed. So I guess I will wait for 8 and try again.

I'm curious to see some screenshots with the new theme.

It seems somebody does some work on themes about every year or two.

I think this article shows one (barely): https://www.omgubuntu.co.uk/2022/01/wine-7-0-released-with-t...

Was anyone able to run Foobar2000, the best music player/manager of all time, on Mac?

I always had audio glitches on Macos <10.15 and didn't manage to get it running with Macos >10.15 due to x64.

The native Mac version is by far not sufficient unfortunately.

Interesting how after so many and great improvements on Audio and Video stacks, but the Smart Card and Certificate Management stack is pretty not existing/not working.

Hope it will improve someday on this direction as well

Looking forward to when Word Perfect works and I can finally move my parents office off Windows.

I'm looking forward to the day when everyone gets moved off of Window$... :)

Isn't linux still falling farther behind? If I want to use my linux desktop to run some of the gazillion inexpensive apps written for the computerphones or any of the bazillion high-prestige apps written for the Apple desktops, what are my chances?

Apple desktop: slim chance at best. There's a similar effort to port cocoa. iOS: Forget it.

Android: Apps that work on x86 smartphones run easily on x86 desktops; apps that only work on arm phones require emulation on x86 and it's substantially more complex to get working, but you can do it.

> Apple desktop: slim chance at best. There's a similar effort to port cocoa. iOS: Forget it.

For reference, the macOS not-an-emulator is Darling [0] but yes, there does not seem to be enough interest for it to catch up any time soon.

[0] https://www.darlinghq.org/