Trying to run LabVIEW 3.0.1 in Mini vMac on my 3DS and it's crashing on startup

[Sparkette]

Does anyone know how to fix this error that appears when starting up LabVIEW 3.0.1?

Failure: "units.c", line 334
LabVIEW version 3.0.1
Please record the preceding information
and contact National Instruments for
Technical Support

I don't plan on contacting NI because I doubt this version is still supported, at least not without a contract.

[ensegre]

https://www.gamebrew.org/wiki/Mini_vMac_3DS

why? why? why?

[Sparkette]

1 hour ago, ensegre said:

https://www.gamebrew.org/wiki/Mini_vMac_3DS

why? why? why?

For fun. 😄

"Science isn't about why; it's about why not!" - Cave Johnson

[Sparkette]

Here are the contents of LV_Fail.txt (I am aware the year is set wrong):

---
Wed, Jan 24, 1996 2:43:05 PM
Failure : "units.c", line 334
LabVIEW version 3.0.1
Please record the preceding information and contact National Instruments for Technical Support
0x001A8F4E MacStackCrawl+204
0x001AA17A Die+38
0x001AA118 DBAssert+128
0x0021C436 InitUnitManager+298
0x001BA1B6 InitApp+1860
0x00198406 WBackground+78
0x00187080 main+32766

 

[ShaunR]

21 hours ago, ensegre said:

why? why? why?

Great song.

[hooovahh]

On 1/24/2026 at 1:22 PM, Sparkette said:

"Science isn't about why; it's about why not!" - Cave Johnson

"I don't want your damn lemons!"

[Mefistotelis]

On 1/24/2026 at 8:45 PM, Sparkette said:

0x0021C436 InitUnitManager+298

This is clearly the assert just after `DSNewPClr()` call.

Anyone knows what packer tool was used to decrease size of LabVIEW-3.x Windows binaries? It is clear the file is packed, but I'm not motivated enough to identify what was used. UPX had a header at start and it's not there, so probably something else.

Anyway, without unpacked binary, I can't say more from that old version.

Though the version 6.0, although compiled in C++, seem to have this code very similar, and that I can analyze:

 

  if (gTotalUnitBases != 9)
    DBAssert("units.cpp", 416, 0, rcsid_234);
  cvt_size = AlignDatum(gTDTable[10], 4 * gTotalUnitBases + 18);
  gCvtBuf = DSNewPClr(cvt_size * (gTotalUnits - gTotalUnitBases + 1));
  if (gCvtBuf == NULL)
    DBAssert("units.cpp", 421, 0, rcsid_234);

The 2nd assert seem to correspond to yours, even though it's now in line 421. It's clearly "failed to allocate memory" error.

 

[Rolf Kalbermatter]

On 1/27/2026 at 12:56 AM, Mefistotelis said:

This is clearly the assert just after `DSNewPClr()` call.

Anyone knows what packer tool was used to decrease size of LabVIEW-3.x Windows binaries? It is clear the file is packed, but I'm not motivated enough to identify what was used. UPX had a header at start and it's not there, so probably something else.

Anyway, without unpacked binary, I can't say more from that old version.

Though the version 6.0, although compiled in C++, seem to have this code very similar, and that I can analyze:

 

  if (gTotalUnitBases != 9)
    DBAssert("units.cpp", 416, 0, rcsid_234);
  cvt_size = AlignDatum(gTDTable[10], 4 * gTotalUnitBases + 18);
  gCvtBuf = DSNewPClr(cvt_size * (gTotalUnits - gTotalUnitBases + 1));
  if (gCvtBuf == NULL)
    DBAssert("units.cpp", 421, 0, rcsid_234);

The 2nd assert seem to correspond to yours, even though it's now in line 421. It's clearly "failed to allocate memory" error.

 

It could also be the assert a few lines above or somewhere there around there. Hard to say for sure.

gTotalUnitBases being not 9 is a possibility but probably not very likely. I suppose that is somewhere initialized based on some external resource file, so file IO errors might be a possibility to cause this value to not be 9.

The other option might be if cvt_size ends up evaluating to 0. DSNewPClr() is basically a wrapper with some extra LabVIEW specific magic around malloc/calloc.

C standard specifies for malloc/calloc: "If size is zero, the behavior of malloc is implementation-defined" meaning it can return a NULL pointer or another canonical value that is not NULL but still can not be dereferenced without causing an access error or similar. I believe most C compilers will return NULL. The code definitely assumes that even though the C standard does not guarantee that.

AlignDatum() calculates the next valid offset with adjusting for possible padding based on the platform and the typedef descriptor in its first parameter. Difficult to see how that could get 0 here, as the AlignDatum() should always return a value at least as high as the second parameter and possibly higher depending on platform specific alignment issues.

This crash for sure shows that some of the API functions of Mini vMac are not quite 100% compatible to the original API function. But where oh where could that be? This happening in InitApp() does however not spell good things for the future. This is basically one of the first functions called when LabVIEW starts up, and if things go belly up already here, there are most likely a few zillion other things that will rather sooner than later go bad too even if you manage to fix this particular issue by patching the Mini vMac emulator.

Maybe it is some Endianess error. LabVIEW 3 for Mac was running on 68000 CPU which is BigEndian, not sure what the 3DS is running as CPU (seems to be a dual or quad core ARM11 MPCore) but the emulator may get some endianess emulation wrong somewhere. It's very tricky to get that 100% right and LabVIEW does internally a lot of Endianess specific things.

Edited 1 hour ago by Rolf Kalbermatter