Choosing the EDIABAS implementation

Test0 talks to BMW ECUs through an api64.dll that implements the EDIABAS API. Two implementations exist:

Test0 ships with EdiabasLib and works out of the box — no setup needed. Just setup your adapter in settings. About 80% of users will never read past this line. The rest of this document is for the 20% who want to switch to BMW's implementation.

Switching implementations

Open Tools → Settings... → EDIABAS. Near the top there's a combo:

Which EDIABAS implementation are you using? [ EdiabasLib | BMW EDIABAS ]

Pick the one you want, click Apply, restart Test0. That's the whole procedure. No file renames, no DLL copying, no PATH editing.

How it works under the hood

Older Test0 builds put api64.dll next to testo.exe, which meant switching implementations required physically renaming files (Windows always loads api64.dll from the exe directory first, before consulting %PATH%). Current builds avoid that:

• The bundled EdiabasLib payload (five files) lives in <install>/ediabaslib/, not next to testo.exe. A testo.exe.config next to the exe tells the .NET CLR to probe that subfolder too.
• Test0 doesn't open api64.dll until it's actually needed, so the process starts up with no EDIABAS choice locked in yet.
• At startup, Test0 reads the combo's choice from testo.ini [ediabas] implementation and prepares the DLL search path:
  • EdiabasLib → adds the ediabaslib subfolder to the DLL search path (so siblings like ApiInternal.dll resolve) and preloads ediabaslib/Api64.dll by absolute path.
  • BMW EDIABAS → does nothing. Windows uses its normal search order (app dir → System32 → CWD → %PATH%) and finds BMW's api64.dll via %PATH% from C:\EDIABAS\Bin.

Either way, by the time the first EDIABAS call fires, Windows is set up to load the right DLL.

The combo is the single source of truth. Restart is required only because the DLL search path is fixed at first-load time.

Prerequisites for BMW EDIABAS

You need BMW's tools installed (ISTA / Tool32 / INPA — any of them deposits the EDIABAS runtime at C:\EDIABAS\Bin). Verify by opening a Command Prompt and running:

where api64.dll

You should see C:\EDIABAS\Bin\api64.dll. If not, BMW's installer didn't add C:\EDIABAS\Bin to your system PATH — add it manually under System Properties → Environment Variables → Path.

ECU files come from BMW's own EcuPath= entry in C:\EDIABAS\Bin\ediabas.ini. The ECU files label at the bottom of the ECU Jobs window confirms which folder Test0 is reading from.

What's currently loaded

Same Settings page, the Currently loaded panel near the bottom shows the path of the DLL Windows actually mapped into Test0, plus version and copyright. Use it to verify your combo choice matches reality:

If the panel is empty / says "api64.dll not loaded into this process", Test0 hasn't made any EDIABAS call yet. Trigger one — e.g. open File → Detect ECU, or run a script that calls scripting.apiInit() — then reopen Settings.

If the panel disagrees with the combo (e.g. combo says BMW but Currently loaded shows EdiabasLib), check that you restarted Test0 after changing the combo. The DLL is locked into the process on first load and can't be swapped live.

Detecting where EDIABAS lives on this machine

Click the Menu button at the bottom-left of the Settings dialog → Detect EDIABAS installations.... The detector scans:

• The Windows registry (HKLM\…\BMWGroup\ISPI\ediabas, HKLM\…\Softing\EDIABAS, legacy keys)
• The EDIABAS_CONFIG_DIR environment variable
• Every directory listed in %PATH%
• Common install paths (C:\EDIABAS\Bin, C:\Program Files\BMW\ISPI\TRIC\Ediabas\Bin, C:\Rheingold\Ediabas\Bin)

The dialog lists every candidate it finds. This is discovery only — it doesn't switch implementations (the combo does that).

Troubleshooting

ECU dropdown is empty / "no ECUs found" / wrong list Wrong implementation combo, or the ECU files path doesn't point where you expect. Open ECU Jobs window — at the bottom there's an "ECU files: …" label showing the absolute folder Test0 is actually reading from. If that's wrong, fix the combo in Settings → EDIABAS → Apply, restart Test0, then re-open ECU Jobs.

Could not load file or assembly 'ApiInternal, Version=…' The EdiabasLib payload in <install>/ediabaslib/ is incomplete — one of the five files is missing. Reinstall Test0 to restore them.

Test0 starts but every job times out / no ECU response (with BMW EDIABAS) BMW's api64.dll is a tiny shim that spawns a 32-bit helper process (api64.exe) which loads the real EDIABAS engine (ebas32.dll). If any of those are missing from C:\EDIABAS\Bin, the shim can't start its helper. Reinstall BMW's tools to restore the full set.

Settings panel says Currently loaded: (api64.dll not loaded into this process) Test0 hasn't called any EDIABAS function yet. Trigger one — File → Detect ECU, or run a script — then reopen Settings.

Currently loaded shows the wrong DLL after switching the combo Restart Test0. Windows locks api64.dll into the process on first load and won't swap it live.

BMW EDIABAS loads but jobs fail with API errors Open ediabas.ini (Settings → Menu → Open ediabas.ini location). Common things to check: Interface= (STD:OBD, STD:OMITEC etc. — must match your adapter), EcuPath= actually exists and contains .prg files, Simulation=0 if you want real comms.

I have an older Test0 install with api64.dll next to testo.exe The installer for current builds deletes the old top-level Api64.dll/ApiInternal.dll/apiNET464.dll/EdiabasLib.dll/EdiabasLib.config (and any *.disabled rename leftovers) before laying down the new subfolder layout. If you're updating manually from a zip, delete those files yourself first — otherwise Windows finds the stale top-level copy and the combo can't switch you to BMW.

Startup warning: "EdiabasLib not found" Combo is set to EdiabasLib but Test0 can't find Api64.dll in either the ediabaslib/ subfolder or next to testo.exe. Either reinstall Test0 to restore the bundled files, or switch the combo to BMW EDIABAS if that's what you actually want.

Using BMW EDIABAS from a non-default install (Rheingold / Program Files / etc.) Test0's BMW path resolver probes a few common locations and walks %PATH%, but it can miss unusual installs. Open Settings → EDIABAS → Menu → Detect EDIABAS installations... once; picking your install from the list saves the path to testo.ini, and the ECU resolver picks it up on the next start. (After the DLL has been loaded once, the resolver also uses its actual on-disk location, so this only matters for the very first ECU operation after install.)

Why a combo and not auto-detection?

Auto-detecting the loaded implementation requires calling EDIABAS once at startup (which loads api64.dll into the process so its identity can be read). That takes 1–3 seconds on first run — visibly slow.

The combo trades that for a static config: EdiabasLib is the bundled default (so first-run works), and BMW users flip the combo once. The choice is persisted in testo.ini under [ediabas] implementation. Change it any time via Settings; restart Test0 for the new DLL search path to take effect.