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.
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.
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.
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.
That’s not true either. There’s no such distinction. A program using a GPL library (such as the kernel) is considered as a derivative work according to the FSF.
Canonical legal (for ZFS) decided that distributing a non-GPL module is fine, as did NVIDIA for their GPU drivers.
If the GPL is considered as enforceable on that front (which was _not_ tested), a lot of things would change.
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.
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.
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
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:
> 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.
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'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.
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.
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.
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.
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.
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.
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.
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…
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.
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!
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.
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.
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.
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.
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.
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'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.
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.
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.
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 .
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.
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.
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.
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.
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)
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
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.
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.