RP2350 and Pico 2 - things missing

Also Lattice C and the compiler in XENIX-286.

Not if you were stuck programming for MS-DOS or Windows, unfortunately.

I briefly programmed for MS-DOS at the same time as XENIX but I have managed to avoid ever writing anything for Windows - I've almost managed to avoid ever having to even use Windows but Dell scupppered that record by buying a PPOE, putting the B in org and making us all use Dells running Windows - so I left.

Sure it was. Except it was only giving the Intel market what the users of other CPUs (Motorola, NatSemi) had been enjoying for years.

Sure there's always plenty of fresh air in the fields but this was in the sewer.

You are lucky. Sadly my employers have customers (mainly in Asia) that insist we provide the same software for both Linux and Windows. Quite often we have issues making stuff as reliable on Windows as on Linux and then we find that the customers ran up the Windows version once to check it worked and then use the Linux versions. But they *must* have a Windows version. And now we have the clusterfuck that is Win11 and lots and lots of stuff that no longer works and driver signing issues and.... Still it keeps me fed and off the streets.

I don’t see why that should be “sad”. I would describe it as a “revenue opportunity” ...

And then it took the Windows/DOS world about another decade to transition to properly 32-bit APIs.

And there it seems to have got stuck: even on today’s 64-bit machines, Windows programs still use “Win32”.

Win32 is the name of the API.

Why is it not “Win64”?

The 64bit version is the same API compiled for 64bit instead of 32bit.

IIRC Win32 API first appeared 30 years ago and the name stuck as it differentiated it from other APIs. Now there are no new 32bit Windows versions on sale the name quietly changed in MS docs to Windows API.

If you say Win32 to people who develop for Windows then they know what you mean.

That’s the trouble. It hasn’t really adapted to the availability as standard of 64-bit integers, for example.

Compare the POSIX APIs, where they were careful to use generic types like “size_t” and “time_t”, so that the same code could be compiled, unchanged, to work on both 32-bit and 64-bit architectures. Not something Windows code can manage.

You can do this on Windows too, but they had to bastardise their C compiler for people that hadn't. It's the only one that on a 64 bit platform that has long as 32 bits.

Windows:-

int=32 bits, long=32 bits, long long=64 bits

Everyone else in the bloody world:-

int=32 bits, long=64 bits, long long=64 bits

---druck

The original PDP on which C was written had int 16 bits and long 32 bits K & R specifically said that no size should be inferred for int. It was the length of a native word on the machines

(Almost everyone; Cray had 64-bit int.)

THe Windows approach is well within what the C language spec allows, and simplified the adaptation of existing Windows application code to 64-bit platforms. The equivalent exercise in Linux needed attention to anything that made (sometimes invisible) assumptions about the definition of long.

I don’t think I’d fault either decision though the fact that we’ve ended up with two conventions does make writing/maintaining portable code a bit more annoying, though not really any more so than the slightly different set of things compilers warn about or the lack of GCC compatibility from MSVC. I think MS should bow the inevitable and replace cl with Clang.

Portable code should only rely on the standards not implementations, some very weird possibilities are legal within the standard.

There are always the int<n>_t types for when size matters.

Yes, from what I remember of the 90s, Microsoft code used typedefs, Int32, Int64 or maybe even Macros for types. Big projects sometimes used their own typedefs. I never liked it. I used int and long, but I recognised my code was suboptimal.

Then I moved to Csharp and Java and stop worrying :-).

C was s*it, for not making types explicit, subsequent OS software developers were just polishing the turd.

Most code that cares seems to use things like int_32 or long_64 where it matters and macro expand that on a per target hardware basis

Life is not always that simple and declaring how things ‘should’ be does not fix a single line of code.

One of the public APIs we support largely uses ‘long’ and ‘unsigned long’ for integral values, which causes occasional issues with our cross-platform code. For example ‘unsigned long’ has the same size as ‘size_t’ on Linux, but not on 64-bit Windows.