Mefistotelis

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.

You did mentioned the articles are included on this particular CD: https://archive.org/details/labview-technical-resource-library-of-back-issues-windows-macintosh-v1.0

https://archive.org/search?query=subject%3A"labview+technical+resource"

There are already few completely automated captcha solving services, last year they claimed 70% success rate, now they say the success rate is higher than humans do, but much faster. And this will improve fast, with LLMs getting more integrated with image recognition. With various degree of notoriety, this affects the whole Internet. We just need a new general method of recognizing bots.

Thanks @Rolf Kalbermatter. You're right about the `.lib` files - just looked at one and it's just a collection of stubs. It's not for dynamic symbol loading, instead it calls `CallLVRT`, giving it a static struct as first parameter - this first parameter contains the symbol name to actually call. There's more than a thousand of symbols in that `.lib` and all of them do that. For compiling the LV 2.5 ASM - it would require some minor changes, but not the arch conversion - toolchains today still have `-m32` or `-arch i386` or other parameters to switch to 32-bit, and PC OSes, at least for now, offer 32-bit user space. (I'm actually curious about compiling 64-bit app with 32-bit sub-module inside.. seen people experimenting with code segment selector to get to 32-bit mode. Requires mmapping any memory to be accessible in 32-bit space. Not sure if it works outside Linux though.) Still, it's just ASM - with todays disassembly tools (and some minimal manual work) I can get compilable ASM for any version of LV, the only difference would be lack of comments and lack of names for static symbols.

When I was still at university, I've heard an anecdote about NI once releasing complete source code with a specific LabVIEW version, by mistake. I think I later saw a confirmation on one of LV-related forums (not sure if this one). But after a quick search, I can't find it. Anyone knows more about this? I'm not really interested in working on LV sources, but would be interesting to just compile that with a modern toolchain. Looking at the releases I have: * cintools-2_5 has a few ASM files, including assembly source for LVRT. But doesn't look like the whole thing - there's 400k of `.asm` and `.h` files in total. * cintools-3 has a header (extcode.h) which is a concatenation of all headers from LV - so there's 327k of headers. No sources though. * cintools-6_0 only has standard cintools headers, but there are lots of `.lib` files included (static libraries are a collections of .obj files). So no source code, but there seem to be enough `.obj` files for the whole labview - 1.2M in total the releases after 6.0 don't seem to have much interesing stuff in them. And considering when I was at university, the rumored release must have been not newer than v8.0.

The compiled project is clearly in LEIF block.

When I'm trying to figure out checksums, I'm first trying various online tools which compute them. They often support many varieties. Checksum byte is very rarely used for checksum. I've seen once an algorithm which used that area, assuming it is zero filled. Count is sometimes included, sometimes not - hard to judge. If a simple check with few sites/tools won't help, i'm going into REing the code. It is simpler than checking all possibilities. Also, implementations of CRC used in various products are often incorrect, ie. incorrectly treating sign, byte order, or just having a typo. So sometimes it's not possible to figure out the algorithm without reversing the target code.

There are two APIs to graphical systems: X-window and Wayland. X-window contains compatibility layer for Wayland, Wayland contains compatibility layer for X-window. And most libraries which help creating GUIs allow to compile the same user code for both. Microsoft won by donating Windows to schools, and providing courses for teachers. This paid out over years, making Windows a template by which all OSes are judged. Now, at least is EU, there is a movement to require open-source OS in all public institutions. This should, over years, remove some of that bias.

Depends on a kid. Depends on his interests. If you're just after programming a PC: Scratch is quite popular. There's also similar thing called Blocky. If the kid won't get into things unless that's a game: Baba is you is a great game for kids. He probably already has some favorite games, and many games today use LUA. So he could also start modifying a game he knows using LUA scripts. If he prefers to drive something mechanic, like a robot: There are some DJI products for kids, like Robomaster or Tello. Not the cheapest, but high quality. You can program these. There are actually many programmable robots and robotic arms for kids, just search the net. Arduino is also easily programmable, and there are many sensors, LEDs, displays, motors etc. which you can drive with it.

I actually don't care enough for LV to get triggered by the first sentence. But the last one... 😡

Tough decisions are definitely required to put LV back on its feet. But those also have to be correct decisions - and that's not easy to judge at this point. Approach to some features may change now, as "this design flaw was solved in NXG" is no longer an argument.

Read this: https://en.wikipedia.org/wiki/Name_mangling Symbols are decorated this way only in C++. If you just don't want the decoration, compile with C compiler, or use `extern "C" {` and declare your functions within that block. For how LabVIEW handles name mangling - someone who knows LV would have to reply.

Typically, people tend to use 'repo' from Android to make a project from multiple git repos. It's a lot more flexible than submodules. With 'repo', you create a 'manifest' (or multiple manifests) which contain all repositories to be included, with indication on branch and commit to be used. It's intuitive, and anyone who worked with Android already knows how to use it.

Right; sorry, I had attention span only to read a few last posts. From a few projects I looked into, only text files like *.lvproj files seem to be detected. Projects with only VIs in them are not marked as LabVIEW, no matter how much are there or what's the file/project name.