1) Do not free memory allocated in one language (even more: in one library unless explicitly documented so) into another. Rust can use a custom allocator, and what it uses by default is an implementation detail that can change at a blink.
2) Do not use Vec<T> to pass arrays to C. Use boxed slices. Do not even try to allocate a Vec and free a Box... how can it even work?!
3) free(ptr) can be called even in ptr is NULL
4) ... I frankly stopped reading. I will never know if Rust actually needs Go's defer or not.
To run win32 applications inside Windows operating systems that are too modern (e.g. for 16bit apps), in a browser or on macOS (recent versions of macOS do not have 32bit support and IIRC runnin 32bit wine was not easy).
Of course these are my guesses, I don't think the "purpose" of boxedwine is ever explicitly stated.
... There are plenty of those kind of games being sold and developed, though.
I only play single player stuff and have a backlog that just keeps increasing, I can't keep with the pace. They aren't the most publicized AAA titles though (BG3 probably bring an exception given its popularity, and the Zeldas thanks to Nintendo).
It's just like music, where there's plenty of good one being made, but can't be found anywhere close to the top 10 hits or on radio (at least, for the kind of music I like).
So yeah... One can dream, but the dream is, for once, alive (mostly thanks to GoG, Steam and Humble).
Pentium 60MHz was P5 though, not P54C ... if I'm not mistaken. IIRC the slowest P54C was the 75MHz one as they all had 1.5x multiplier or greater? Again, I wouldn't rule out my memory being wrong.
Compiling? Staying cool and not turning on the fan? Avoiding unnecessary waste?
Really anything rather than a thing that has only drawbacks.
As far as readability goes... can't see a difference with monospace text, maybe even worse as fonts tend to be thinner and need adjustments. Maybe a little better with proportional text on websites and documents.
One suggestion: where you talk about using AsRef<[T]>, might be worth suggesting IntoIter, where it makes sense? IIRC that's what std uses for functions that aim at being generic over data structures and iterators (I might be remembering wrong, though).
In any case let's not digress from the truth: amazing list.
I have an EV, no gas car and I'm super happy about that.
And yet when I needed to rent a car, I rented a gasoline one.
Why?
Because car rental is pretty much the worst case for an EV.
If I rent a car I'm likely abroad, with zero knowledge of the recharge network and often not great options in terms of costs because most are national (at least, here in Europe, only notable exception being Ionity).
I'm also likely to drive long distances, with no routine, and little planning capacity.
And whatever other reason one would pick an EV for (noise, pollution, fuel cost, one pedal drive comfort etc.) they are all negligible when applied to a 2 weeks vacation.
Reasons:
- practically every developer who is remotely interested in assembly programming knows the x86 basics and most experts have a better knowledge of x86 than other architectures with the possible exception of ARM
- x86 is very hard for the hardware implementation, for the programmer (especially with the x86-64 improvements) is not bad at all. Its bigger defects are variable instruction length, something that has no impact on coding, and tge amount of legacy stuff that exists mostly for backward compatibility (e.g. x87, enter/leave, bcd instructions, hw task switching, segments, real mode and v86 mode, etc.) and are just being ignored by programmers as stuff that is now irrelevant if they have not been removed from 64bit long mode at all.
- I don't know modern MIPS, but the MIPS architectures of the past were not programming friendly at all, with stuff like delayed slots (basically instructions that are executed even if the code branched somewhere else), heavy reliance on the compiler to provide perfect instruction order, etc
"someone" is probably a dependency you include that, for one reason or another tries to revert the policy to a lower level of enforcement. Might be because the dependency needs the lower security policy to work, or because it's a framework that comes with an insecure default, or might be because it accepted a couple PRs from JiaT75.
I think it's a sensible choice: try lowering the policy and everything blows up. Much better than the alternative of silently ignoring the call or, even worse, silently lowering the policy
From a cursory (icony?) view, it seems to be missing the ones from moricons.dll, but memory is foggy and it might be that moricons.dll had been dropped by win98. It's been 26 years, wouldn't be surprised to find my memory is wrong.