Office 2003 still works absolutely fine and is free if you bought a licence some time in the past. It doesn't have the stupid ribbon or any other annoying new feature.
I recently wrote a macro so that Word could call an AI API to do AI-assisted translation, works like a charm.
Main problem with office 2003 is that it can't reliably open docx and friends making it more or less non compatible with anything newer. Being able to open only docs you create yourself isn't very useful in a collaborative environment.
The main advantage of office 2003 of course is that it's the last office without activation and other crap: you pass the serial and own it for life, it won't bother you again.
I wantwd to only use 2003 but after the 10th time I argued with a person that sent me a docx for editing I gave up.
Office 2003 can absolutely open docx and xlsx and pptx files. It is annoying because it usually opens those in read-only mode, and then you need to "save as" to do your modifications. But it works fine otherwise.
“View” unfortunately isn’t the same as “Open and edit”, and in business you need to do the latter. Otherwise we’d be 100% libreoffice from the start. Yep, that’s the moat.
It's been a while, but I think what they're saying is that you have to "save as" in order to be allowed to edit. Office 2003 thinks of the compressed versions as export formats rather than internal formats.
> I think what they're saying is that you have to "save as" in order to be allowed to edit.
The issue is that roundtripping between Office 2007+ and Office 2003 is unreliable and will often result in corrupted files.
Using Office 2003 (with Compatibility Pack add-on to open xlsx and docx) is ok for isolated work but can be unreliable for collaborative back & forth editing depending on what features are used. E.g. cell colors used in Excel 2007 xlsx get corrupted in Excel 2003 xls.
It's a completely different format. Iirc .doc files are basically implementation defined files and consist of c-structs dumped to disk. .docx is a properly specified format of compressed xml.
It's not "C structs dumped to disk". It's https://en.wikipedia.org/wiki/COM_Structured_Storage, which is basically a filesystem-in-a-file. And it has been documented for a long time, ever since Microsoft was forced to write docs for Office file formats because of antitrust:
> The main advantage of office 2003 of course is that it's the last office without activation and other crap: you pass the serial and own it for life, it won't bother you again.
That's actually not true, Office has had activation since XP (2002), so 2003 is included in that.
I used to love Office 2003, and I still do. But... just use LibreOffice at this point. It has an interface that reminds a lot of classic Office, but at least it's more updated and probably safer. It also supports newer file formats.
It works fine if the user is ok with the features from 2003. E.g. Excel 2003 is limited to smaller spreadsheets of 65536 rows by 256 columns but Excel 2007+ can handle larger worksheets of 1048576 rows by 16384 cols.
I also recently used Excel's new LAMBDA() function which was introduced 2020. In earlier versions, it required writing a VBA UDF to accomplish the same task of assigning a temp variable with a ephemeral value to calculate on intermediate values. VBA is a workaround but LAMBDA() is nicer to use because Excel will throw up scary security warnings whenever the xls file containing VBA macros is opened.
I might be able to get by with Word 2003 more than Excel 2003.
You're right about Excel; however, I think big data files should be handled in a db rather than in a spreadsheet. And sqlite can query Excel files (with an extension), and it's super fast and you can use any function you want, or write your own.
>; however, I think big data files should be handled in a db rather than in a spreadsheet. And sqlite can query Excel files (with an extension)
A lot of normal users of Excel are not users of database software like SQLite or MS Access. That's too cumbersome. E.g. they download a csv file that has ~100000 rows (which really isn't that "big") and clicking on it gets them an instant visual grid as a GUI in Excel. Slicing & dicing and pivoting data is way faster in Excel than coding SQL WHERE GROUP BY statements. I've commented previously on why databases are not substitutes for the workflow ergonomics made possible by spreadsheet tools : https://news.ycombinator.com/item?id=30987638
It's similar to reasons why Python/R or Jupyter notebooks are also not substitutes for Excel for the typical users of Excel.
The low row count of 65536 in Excel 2003 was just a legacy limitation of 1980s 16-bit computing that was carried over into 32-bit computing for many years for backwards compatibility reasons. Spreadsheet users don't really want to switch to databases or Python just to get more usable rows than 65536.
> The scenario of "I just sent you an xlsx where the rows highlighted in red are problems and if you can just add your notes to column K, that would be great. Thanks!" -- is not easy in other tools that are not spreadsheets.
There are no words to tell how much I hate that!!! ;-) Users are too creative. Some will merge some cells and not others and boom the file can't be properly sorted anymore. Many will use font color, font weight or background color to mean wildly different things, which is very difficult or impossible to sort or do a sumif over. Others will add footnotes, because why not?, and links to spreadsheets that never leave their own device, or mini-blank-rows for spacing and general layout, etc. It's completely insane.
> I think big data files should be handled in a db rather than in a spreadsheet.
Your side lost completely. Pop a signal flare or build a bonfire, maybe someone can rescue you from the island you've been living on since the war ended.
If Microsoft had adopted this attitude, then by now Excel's market share would probably be 0% and Google Sheets' would be 100%. Microsoft doesn't add features because they like bloated software; they add features because the market demands them, and the market demanded support for more than 65,535 rows.
Although I agree about the ribbon and UI, I think Excel 2003 in particular feels quite limited today - it can deal with a max of 255 columns in a sheet and is missing some of the most useful functions (SUMIFS and XLOOKUP spring to mind especially but also the newer array functions like SORT).
Sumif (without the s) worked in Excel 4 (1992), you just had to enter it with CTRL+Enter and use curly braces IIRC. I used it to build dashboards. Not sure what problem sumifs solves beyond sumif.
XLookup sure is useful but again you can probably replace it with a combination of vlookup and hlookup (or index match).
Regarding the size... If you're dealing with huge spreadsheets it's really better to use a proper db. Or even manipulate data with sqlite. sqlite can query xlsx files directly (with an extension), it's extremely fast and stable.
The problem with the column limit is not so much about huge datasets as limiting flexibility in how you can lay things out - 65k rows and 16.7m cells are plenty and I’d be wanting to use a database well before I got there. But 255 columns does feel quite constraining.
And whilst you can work around lack of XLOOKUP or SUMIFS using the older functions, again it constrains how you lay things out (eg VLOOKUP needs you to presort your table by the lookup column if you don’t want an exact match) and this can often result in sheets which are much more unwieldy and slow to calculate.
I recently wrote a macro so that Word could call an AI API to do AI-assisted translation, works like a charm.