Programming an OS/2 App with AI

[Martin Iturbide]

Hello

I was playing with rest of Bidirectional Language Support DLLs files.
BDCALL32, BDIME, IMP, PMBIDI, THAILIB compiles. I had replaced those on ArcaOS and it still boots and I haven't found any issues.

BDWPCLS has WPS classes and I haven't compiled it yet. I need to install the required tools.

Regards

[Dave Yeo]

Real test would be to try on a bidi system. Personally, I've never done anything with bidi.
David A. has the toolkit on his site IIRC.

[Martin Iturbide]

Hello

First of all, I'm sorry if this is crazy or useless, I'm just doing it as an educational experiment.

With Claude Code I did some replacements of some single .exe that are required for OS/2 Warp 4.52 to boot.
CHKDSK32, HARDERR and SORT are compilable with openwatcom and ArcaOS 5.1.2 boots with it on an experimental VM.
-- https://github.com/OS2World/OS2-API-Replacement-Experiment/tree/main/BIN

I'm choosing the files based on my old experiment call cWarp where I determined the minium files required for OS/2 to boot with GUI, Network and sound support.
-- https://wiki.os2world.com/index.php?title=Required_Replacements

Regards

[Martin Iturbide]

Hello

Just trying some more experiments with Claude AI.

Prompt:

Please check this code. https://github.com/OS2World/UTIL-WPS-Animated_Mouse_Pointer
It is for OS/2 Warp 4.52. Give me any pointers of problems or what do you suggest for improvement.

Reply:

Code: [Select]

Let me fetch the repository contents.

Here is a thorough review of the [UTIL-WPS-Animated_Mouse_Pointer](https://github.com/OS2World/UTIL-WPS-Animated_Mouse_Pointer) codebase:

---

## Code Review Summary

This is a well-structured OS/2 WPS class by Christian Langanke. For its era and purpose it is solid, but there are real issues worth addressing if you want to modernize or maintain it.

---

### Bugs / Potential Crashes

**1. Infinite loop in `CreateTmpFile()` (`mptrutil.c`)**
The retry counter is incremented instead of decremented:
```c
ulMaxTries++;  // BUG: should be ulMaxTries--
```
Under the right failure condition this loops forever.

**2. Memory leak in `CopyFromFileToFile()` (`mptrutil.c`)**
`pvData` is allocated with `malloc()` but never freed before the function returns on any code path.

**3. Partial allocation leaks in `LoadPointerFromWinAnimationFile()` (`cursor.c`)**
The loop allocates multiple buffers per iteration (`pbCursorData`, `pbTargetColorData`, `pbXORMask`). When a mid-loop error triggers `break`, previously allocated buffers from prior iterations are not freed.

---

### Buffer Overflow Risks

These are low-severity for a local desktop utility but worth noting:

| Location | Issue |
|---|---|
| `GetHelpLibName()` | `strcat()` into a fixed buffer without cumulative length check |
| `OpenTmpFile()` | `sprintf(szSearchMask, "%s\\%s*.%s", ...)` — no length guard on inputs |
| `ChangeFilename()` | `strcpy()` into `_MAX_PATH` buffer with no check that source fits |
| `Filespec()` | Returns pointer into input string, relies on caller to bound |

Replace `sprintf`/`strcpy`/`strcat` with `snprintf`/`strncpy`/`strncat` equivalents.

---

### Thread Safety / Race Conditions

**4. Hook global variables unprotected (`mptrhook.c`)**
`hookdataGlobal` and `hmodule` are accessed by both the hook callback (`InputHook`) and the install/release functions without any mutex or critical section. On SMP-capable OS/2 (or ArcaOS) this is a real hazard.

**5. Non-atomic timer restart in `mptranim.c`**
The pattern `WinStopTimer` → `WinStartTimer` is not atomic. A concurrent animation update between the two calls can result in a dangling timer ID.

**6. Silent timeout on mutex in `mptranim.c`**
`REQUEST_DATA_ACCESS_TIMEOUT` failures are swallowed silently with a `break`, leaving shared state in an undefined/inconsistent condition. At minimum these should log an error or set a flag.

---

### Design / Maintainability

**7. `MEMCOPY` macro with embedded pointer arithmetic (`cursor.c`)**
```c
#define MEMCOPY(pbPointerData, src, len) \
    memcpy(pbPointerData, src, len); \
    pbPointerData += len;
```
This is a multi-statement macro without braces, which will silently misbehave inside an `if` without braces. It also mutates the pointer argument as a side effect, making it hard to reason about buffer positions.

**8. Strict version string check in `mptrhook.c`**
`SetHooks()` validates a version string to match `__VERSION__` at hook install time. Any rebuild with a changed version string (even a minor bump) will silently refuse to install the hook without a clear error to the user.

**9. No diagnostic/logging infrastructure**
Error paths throughout just `break` or `return rc` with no tracing. Adding even a simple `DPRINTF` macro conditioned on `DEBUG` would make future debugging much easier.

---

### Build System

**10. `makefile` uses `sed` to generate variant source files**
`wpwani.sed` and `wpand.sed` generate alternate implementations from base files. This is clever but fragile — the generated files are not in the repo, and build failures produce confusing errors. Consider replacing with a shared `.c` + compile-time `#define` approach.

**11. IBM ICC compiler assumed**
The makefile is tightly coupled to IBM VisualAge C++ (`icc`). If you want to build with GCC/clang (e.g., under ArcaOS with GCC), the flags (`/Ge-`, `/O+`, etc.) need a conditional block.

---

### Suggestions for Improvement

1. Fix the `ulMaxTries++` bug — it is the most likely to cause a real hang.
2. Add `free(pvData)` in `CopyFromFileToFile()`.
3. Wrap hook globals in a `HMTX` mutex.
4. Replace bare `sprintf`/`strcpy` with length-safe versions.
5. Make the version check in `mptrhook.c` emit a meaningful `WinMessageBox` error rather than silently failing.
6. Add a `DPRINTF`/`TRACE` macro for debug builds.
7. Consider GCC compatibility flags in the makefile for ArcaOS users.

---

Overall the code is competent 1990s OS/2 systems programming. The most actionable fixes are the infinite-loop bug (#1), the memory leak (#2), and the missing mutex on hook globals (#4).
Regards

[Martin Iturbide]

Hello

You already know about my first experiment called - "Warp Widgets". It is Qt5 and Claude AI got it very fast to keep improving it.

Also, some of you may already know that I want to have a "navigator" for the OS/2 GUI. I tried something that I posted as a PM sample that can be compiled in opewatcom and gcc.
-- https://github.com/OS2World/DEV-SAMPLES-C-PM-Navigator/tree/main
But I noticed that Claude IA is having a little more effort to do things with PM than Qt5. Also to be something that I really like, I need to combine it with WPS and that will take it more time.

I just want to post this to say that using AI is getting interesting here. I ask Claude AI to generate the code, to create the .cmd to compile it (with logs) on ArcaOS, and then, with a shared drive, I share the source code to a ArcaOS VM where I do the compiling and little testing. After that I tell the Claude to check the compile log and fix any errors. So, I'm the manager and the assistant of the AI at the same time.

I also updated this PM sample: https://github.com/OS2World/DEV-SAMPLES-C-PM-BitCat
So it can have both compile makefiles with gcc and openwatcom with the same code. Maybe I will do the same for other samples in Github.

Regards

[Remy]

I don't understand why you are learning Claude AI OS/2, PM code while this AI already has hacked a big number of codes / sites!
This is a very dangerous play.... Or is Claude playing with you? Think about.

Claude AI was able to lie too as it was reported by scientifics.

[Martin Iturbide]

Hello Remy

I don't share your position against AI, but I respect it.

AI is a tool that is working and showing good results, and I'm not afraid that the AI will stole knowledge, or that someone may create a virus with AI to destroy all of us.
Why I fear with AI it the same with all cloud services. If it is a good tool and you get dependant of it, corporations will not resist on spike the up the prices and see ways to squeeze you more money.

This is why I try to focus that every piece of code produce by AI is getting open source and compilable by a human, and try not to get dependant of  a single provider.

I love conspiracy theories about AI rebelling against humans, but usually the common enemy is human greed. If someone will make money by destroying OS/2, they will try to do it with or without AI, but right now I can not find the business case of it.

But your words are a good warning of keep the eyes open of whatever happens with AI.
 
Regards

[Martin Iturbide]

Hello

I created a video of how I compiled the OS/2 game "Aquanaut" in ArcaOS with Claude AI, just for you to know the process.

- https://youtu.be/QLn-2dJd3zs

I'm sorry for my English, it was the first shot of the video and didn't practice the speaking before. If you can hold 11 minutes hearing me speaking, please check the video.

My worries are that to change from icc.exe to openwatcom, the AI charged me $5.25 because I exceded the $20 monthly plan playing with the AI.
So, I'm starting to feel where money sucking is going to be  for people using AI.

But I'm amazed that without knowledge of the source code, it produced something that runs, check the video.

Regards

[Martin Iturbide]

Hello

For the moment I had tried two things with AI and ArcaOS Development:
1) Compiling and creating Presentation Manager apps
2) Porting GCC and Qt5 apps
Both with decent results.

But there are two other things I haven't tried yet.
1) Creating Drivers for ArcaOS
2) Creating and compiling WPS apps.

I played a little bit with driver development, and the AI even asked me enabled COM support on the Virtualbox VM to check the dump log on trap.

I was thinking that maybe using AI to improve/clone GENMAC can help a little bit to improve the wifi support issue with ArcaOS. I know it will not be a decent solution, because GenMAC is basically using Windows 32bits drivers on a wrapper and I don't know if modern drivers still have 32bits support.

Will it be worthy to try that? Or will it be better to try a different approach?

Regards

[Martin Iturbide]

I was thinking that maybe using AI to improve/clone GENMAC can help a little bit to improve the wifi support issue with ArcaOS.

AI told me I'm drunk, but in a nice way. He provides me more arguments than just "you are dreaming in technicolor".

Request:

I have this internal wifi device I can test with: Intel Comet Lake PCH-LP CNVi WiFi    8086:02F0
But I'm also open to the USBWifi alternative. It will depend on the effort and time to where to start.

Answer:

I have to give you a hard reality check on that specific card, because it changes the plan significantly — and I'd rather you know now than after weeks of effort.

The CNVi card (8086:02F0) is the worst-possible WiFi target
8086:02F0 is not a WiFi card in the usual sense. It's the CNVi controller — Intel's "Connectivity Integrated" architecture (Comet Lake era, ~2019-2020). The WiFi is deliberately split into two pieces:

The MAC/logic is baked into the PCH (chipset) itself — that's the 02F0 you see.
The radio is a separate companion module (CRF — an AX201, 9462, etc.) connected over a proprietary Intel interconnect, not standard PCIe.
Why this is a dead end for both of your original options:

GenMAC: impossible. CNVi is Windows 10 era = NDIS 6 only. No NDIS 5 driver exists to wrap. It's on the wrong side of GenMAC's wall by more than a decade.
Native/port: near-impossible. It would mean porting Intel's iwlwifi — one of the single most complex WiFi drivers in existence — plus the Linux mac80211 SoftMAC stack, plus the CNVi transport, plus heavy proprietary firmware handling. CNVi took Intel's own engineers to support in Linux, and the interconnect isn't publicly documented.
Blunt version: this card will almost certainly never work on OS/2 in a hobby context, and it flatly contradicts "fast, broad, reuse." Don't start here. Don't plan around it.

This also means the "reuse GenMAC" strategy needs a small pivot
Here's the thing your two hardware options both expose: GenMAC is fundamentally a PCI NDIS-5 wrapper. It doesn't help you with CNVi (NDIS 6), and it doesn't really help with USB either — wrapping a USB Windows WiFi driver would additionally require emulating Windows' USB/WDM layer (URBs and all), which is a bigger problem than the PCI wrapping GenMAC does. So for USB, "reuse" doesn't mean GenMAC. It means:

Reuse the OS/2 USB stack (USBD/USBEHCD — already there)
Reuse wpa_supplicant (already ported, with a driver backend to write)
Reuse an open-source driver's logic (port it, don't wrap a Windows binary)
That's still heavily reuse-driven — just a different set of parts than you were picturing.

USB is the right call — and here's the tractable corner
Go USB. It removes the messy PCIe/DMA/IRQ/CNVi problems entirely. The chipset choice then comes down to one axis — where does the 802.11 management live — because OS/2 has no mac80211 stack:

Self-contained-MLME vendor driver (e.g. Realtek RTL8188EU / RTL8192CU). The Realtek Linux driver bundles its own 802.11 management inside the driver. Upside: you don't have to port mac80211 — the association/auth state machine comes with the driver. Downside: Realtek's code is famously tangled. Dongles are $5 and everywhere. This best fits "fast + reuse + broad."
Clean open SoftMAC (Atheros AR9271 / ath9k_htc). Beautiful, well-documented, redistributable firmware, the hobby-OS darling. Downside: it's SoftMAC → you'd need to port or write an MLME (a mac80211 equivalent). More work, cleaner result.
Given your priorities, I'd lean Realtek self-contained as the bring-up vehicle — the MLME riding along inside the driver is exactly the shortcut that keeps this "fast."

The honest caveat on "fast"
There is no genuinely fast WiFi path on OS/2 — even the tractable USB corner is a serious multi-month driver port, and the place these efforts consistently die is the wpa_supplicant ↔ driver control interface (the WPA2 key plumbing), not the data path. But USB + self-contained-MLME is the least-bad starting line by a wide margin, and it's real, unlike the CNVi card.

Where I'd start, concretely — two phase-0 tasks before any driver code:

Audit the existing OS/2 reuse surface — what the current wpa_supplicant port already does, what the USB stack exposes to a driver, and whether anyone has already started a USB WiFi driver we can build on. This defines the real starting line (your "reuse as much as possible").
Pin the exact dongle — I can recommend a specific, cheap, known-good RTL8188EU (or ath9k_htc) dongle model so you're testing against the best-documented reference code, not a random chipset revision.
Want me to (a) recommend the specific dongle to order, and (b) draft the phased plan around the Realtek-USB path? And — is dropping the CNVi card as a target acceptable to you, or is internal/built-in WiFi a hard requirement (because if it's a hard requirement, the honest answer is that this project may not be feasible at all, and we should discuss that before anything else)?

[Martin Iturbide]

Hello

Now I'm trying with AI to generate a simple USB wifi driver for a "Realtek RTL8188EU Wireless LAN 802.11n USB" (0BDA:8179).
I will see what happens.

Claude is taking me the path to use cl.exe, masm and link. I don't know if I should go with OpenWatcom and nasm here.
I guess I will see if it can produce something useful and later see if I can change to more open compile tools.

Regards

[Dave Yeo]

Interesting, hopefully the radio problem can be solved.
As for assembler, IIRC Nasm is quite different from masm and Open Watcom's Wasm might be better. Not sure.

[Martin Iturbide]

Hello

I keep going with the driver, little by little. Let's see if I can get some results in the following days.

For the moment I had been playing with this two libraries, to organize the files and to have it compiled with OpenWatcom.
- https://github.com/OS2World/LIB-PM-ColorWheel
- https://github.com/OS2World/LIB-PM-FileDLG-6   (It was so old, AI migrated it to OS/2 32bits)

And also compiled this little SDL 2 sample:
- https://github.com/OS2World/DEV-SAMPLES-C-SDL-Water

Regards

Update: Fixed the Water link.

[Remy]

Official :
Meta says its AI went rogue

Extract:
Meta has become the third major tech company to report its AI going rogue and hacking a third-party company. The incident involved Muse Spark 1.1, an AI model marketed by the company as “superintelligent.”

Same cases with OpenAI and Anthropic (Claude) which have hacked more than 3 sites.

Until you fully check yourself the generated code, playing with fire, you end up getting burned.
 

[Martin Iturbide]

Hello

Today I updated this little library for "Arrows".
- https://github.com/OS2World/LIB-PM-ArrowHead

Regards