Or why the Commtap Symboliser for PowerPoint won’t be ported to Mac any time soon.
Background
Our symbolising software is built using VBA. With over 250 modules it has tens of thousands of lines of code. This code interacts with other code only available on Windows. Windows installers are used to install it on a computer. These use a combination of Windows Installer XML, Pascal, Visual Basic and batch scripting.
I asked AI (Copilot) (1) how difficult it would be to adapt this code to work on a Mac, and (2) if AI could help. The responses: (1) very difficult, and (2) not much.
Conversation
ME:
I have an add-in for PowerPoint which can be installed on a computer using an MSI installer (for all users) or with an exe installer (for the current user). It makes modifications to the registry – in particular to store a user’s license to use the software. The add-in interacts with shapes and text in slides, it also uses a number of Windows libraries including FileSystemObject, dictionaries, locale, HTTP. How easy or difficult is this likely to be to port to PowerPoint on a Mac – i.e. the changes in code that will be needed?
COPILOT:
Porting a Windows‑built PowerPoint add‑in to macOS is absolutely possible — but the ease or difficulty depends almost entirely on how deeply your current solution relies on Windows‑only technologies. Based on what you’ve described, this is not a light lift. Let me break it down in a way that’s honest, practical, and helps you see where the real work sits.
⭐ High‑level answer
Porting this to Mac will be moderately to very difficult because your add‑in depends on several Windows‑specific components:
- Windows registry
- Windows‑only COM libraries (FileSystemObject, dictionaries, HTTP, locale APIs)
- MSI/EXE installers
- VBA that assumes Windows paths, encodings, and COM behaviour
- PowerPoint object model differences between Windows and Mac
You’re not facing a simple “recompile and ship” situation — you’re facing a partial architectural rewrite.
🔍 Let’s break it down by component
1. Installer + Licensing (Registry Use)
❌ Windows‑only behaviour
- macOS has no registry
- MSI/EXE installers don’t exist
- User‑level vs machine‑level installation works differently
- Licensing data must be stored elsewhere (e.g., plist, JSON file, Keychain)
✔ What you’d need to do
- Replace registry reads/writes with:
- a file in ~/Library/Application Support/<YourApp>/
- or macOS Keychain (if you want secure storage)
- Replace MSI/EXE with:
- a simple PKG installer
- or a drag‑and‑drop installation
- or a cross‑platform Office add‑in deployment method (see below)
Difficulty: High
This is a fundamental architectural change.
2. Windows Libraries (FSO, Dictionaries, Locale, HTTP)
These are all COM‑based and do not exist on macOS.
❌ Not available on Mac
- Scripting.FileSystemObject
- Scripting.Dictionary
- WinHttp.WinHttpRequest
- Windows locale APIs
- Any COM automation
✔ What you’d need to do
Replace each one with Mac‑safe equivalents:
| Windows Component | Mac‑safe Alternative |
| FileSystemObject | Native VBA file functions or AppleScript |
| Scripting.Dictionary | VBA Collection or custom class |
| WinHttpRequest | XMLHTTP (works cross‑platform) or a custom HTTP wrapper |
| Locale APIs | VBA’s Format, Application.LanguageSettings, or custom logic |
Difficulty: Medium–High
You’ll be rewriting chunks of logic, not just swapping references.
3. PowerPoint Object Model Differences
The PowerPoint object model is mostly shared, but:
- TextFrame/TextRange behaviour differs
- Font metrics differ
- Shape manipulation is less predictable on Mac
- Some events don’t fire
- Some methods behave differently or are missing
If your add‑in interacts heavily with shapes and text (which yours does), you will hit:
- layout differences
- measurement differences
- missing methods
- inconsistent behaviour between versions
Difficulty: Medium
Expect debugging and conditional code paths.
4. Deployment Model: VSTO vs VBA vs Office Web Add‑in
This is the biggest strategic question.
If your add‑in is VSTO or COM‑based:
❌ It will not run on Mac at all.
You would need a complete rewrite using:
- Office JavaScript API (Office Web Add‑in)
- or a pure VBA add‑in (with Mac‑safe code)
If your add‑in is VBA‑only:
✔ It can run on Mac, but only after removing all Windows‑specific dependencies.
Difficulty: Ranges from Medium to Extreme depending on architecture.
⭐ Overall difficulty rating
| Component | Difficulty | Why |
| Licensing & registry | High | Requires new storage model |
| Windows COM libraries | High | Must be replaced entirely |
| PowerPoint object model differences | Medium | Behavioural inconsistencies |
| Installer model | Medium | Must adopt Mac‑native or cross‑platform deployment |
| If VSTO/COM add‑in | Very High | Requires full rewrite |
| If VBA add‑in | Medium–High | Requires significant refactoring |
🎯 The honest bottom line
If your current add‑in is:
VSTO / COM / MSI‑based
➡ Porting to Mac = a full redevelopment project
The only viable path is to rebuild as an Office Web Add‑in using JavaScript.
VBA‑only but uses Windows libraries
➡ Porting is possible but requires substantial code rewriting
You’ll need to replace every Windows‑specific dependency and test heavily on macOS.
If you want, I can go deeper
I can help you:
- Map out exactly which parts of your codebase will break on Mac
- Suggest cross‑platform replacements for each Windows API you use
- Outline a migration plan (VBA → cross‑platform VBA, or VSTO → Office JS)
- Estimate effort based on your architecture
- Draft a compatibility checklist for your team
Just tell me what direction you want to explore.
ME:
Someone said to me, couldn’t you just use AI to do that. To be honest I nearly choked on my tea when she said that. I think AI can do some basic things. But to rewrite a code base which has tens of thousands of lines I think that’s unlikely. What’s your take?
COPILOT:
Your reaction was completely justified — the idea that “AI can just rewrite tens of thousands of lines of platform‑specific code” is one of those statements that sounds plausible only if you’ve never actually maintained a real‑world codebase.
Here’s the grounded, technical reality.
🔧 AI can help with code, but it cannot magically port a complex Windows‑bound add‑in to macOS
AI is good at:
- generating small, self‑contained functions
- refactoring within a single platform
- explaining code
- producing boilerplate
- helping you explore alternative patterns
But what you’re talking about isn’t “rewrite this function in a different style”.
It’s architectural migration.
That’s a completely different category of work.
🧱 Why AI can’t simply “port” your add‑in
1. It’s not a translation problem — it’s a dependency problem
Your add‑in relies on:
- Windows registry
- MSI/EXE installers
- COM libraries (FSO, Dictionary, WinHTTP, locale APIs)
- Windows‑specific PowerPoint behaviours
- Windows file paths, encodings, and security models
macOS has:
- no registry
- no COM
- different file system semantics
- different PowerPoint object model quirks
- different security and sandboxing rules
AI can’t “translate” something that has no equivalent.
A human has to redesign the architecture.
2. AI doesn’t understand your business logic or constraints
Even if AI rewrote every line, it wouldn’t know:
- why you made certain design choices
- what edge cases matter
- what your licensing model requires
- what your users expect
- what your performance constraints are
Porting isn’t just code — it’s intent, context, and architecture.
3. Tens of thousands of lines = interdependencies AI can’t safely untangle
Large codebases have:
- implicit assumptions
- hidden coupling
- undocumented behaviours
- legacy decisions
- workarounds for platform quirks
AI can’t reliably infer these.
You can’t just “feed it the repo” and expect a coherent, working Mac version to pop out.
4. Cross‑platform PowerPoint development is fundamentally different
If you move to:
- Office JavaScript API → you’re rewriting the entire add‑in
- VBA on Mac → you’re removing all Windows‑specific components and replacing them manually
AI can assist with snippets, but it cannot design the new architecture.
🧠 So what can AI realistically do?
It can:
- help you identify Windows‑specific dependencies
- propose Mac‑safe alternatives
- rewrite small modules once you define the architecture
- generate boilerplate for Office JS
- help document the migration plan
- assist with testing and refactoring
But it cannot:
- redesign your licensing model
- replace COM with Mac equivalents
- rewrite your installer strategy
- resolve PowerPoint behavioural differences
- guarantee correctness across thousands of lines
Those require human engineering judgement.
🎯 My take, in one sentence
AI is a powerful assistant, but porting a large, Windows‑dependent PowerPoint add‑in to macOS is a human‑led engineering project — not something you can outsource to a chatbot.