Before long you'll have a different LLM embedded in each of a series of cells, and they'll each have an opinion on what you are doing elsewhere in the sheet, and your One True Trusted Overview LLM (named OTTO) will survey them and take a vote and get back to you.
Excel is not even Excel anymore. It’s different on Windows, Mac, web, mobile… And there’s different bugs across all them! My favorite ones have to do with regional defaults.
I was going to say that first versions were technically that, but apparently Excel was never released for DOS, Excel 2.0 was already a Windows application, and 1.0 was only available on Mac.
I don't know that I miss it, it's still around if you look for it. Even here, I find several posts a month doing something this insane and fun, let alone finding out about my friends' personal projects.
“ The emulator is built as a seperate dll which is loaded by the VBA macro. The VBA macro calls the emulator in the dll and gets the output and writes it into the cells in the spreadsheet. ”
Not really in excel. Excel is just the console. Emulator is a native DLL
I was expecting something like the cells being used as registers and the computer being implemented in the spreadsheet itself. Loading an emulator via a DLL and using the spreadsheet as a line oriented display feels like cheating.
By the same logic I can also put a crappy emulator in a dll and make notepad load it via a hook. Linux on notepad.exe. should I make that into a HN post too?
Now that I mention it, I think someone already posted that on HN...
Any practical use cases come to mind? Could you actually interact from Excel cells with Linux userspace, e.g. running a cell's value through a bash script as if applying a formula?
It's focused on web tech as COM add-ins are a huge source of security and instability in Office apps. It's also more flexible for developers as they can modify the backend without having to update the client and the deployment model is significantly easier for admins.
Regarding COM, it wouldn't be that bad when using COM Servers.
However I do agree that although COM as idea is enticing, Microsoft keeps failing to deliver a productive way to use it, despite how much they keep focusing on it for Windows extensibility and API delivery since Vista.
Indeed, nowadays I feel myself a fool for having advocated for WinRT, it was one of the reasons why I returned back to Web and distributed systems, after spending four years back in Windows GUI development land.
And my advice now is for .NET devs, stay with Windows Forms or WPF, depending on which approach they favour.
For C++, I suggest the aging MFC if it has to be on the Visual Studio (still better out of the box experience than WinUI 3.0 for C++, and C++/WinRT is in maintenance anyway), but really Qt or C++ Builder are much better option.
On the other hand, if you can get it to work in the new O365 architecture using whatever JS API they're exposing now, you can call it "cloud-based" or maybe even "serverless".
Wouldn't help with cloud of course, but there's WINE for macOS, isn't there? Or does that version of Excel not allow loading binary libraries such that you could hand it a DLL if WINE translated it?
I just posted the ‘doom on a lightning adapter’ story, and saw this in submissions. I’ll have to tip my hat to the better bizarre ‘X on Y’ post. You win this time, radeeyate.
reply