neonz80

Not every function returnds a boolean. It is probably easier to write HANDLE file = CreateFile(...) than to send in a pointer to HANDLE. Also, this is exactly the same as what libc does with syscalls on Linux etc.

1GB of logs, not content

kernel32 is an official API, you're probably thinking of ntdll. CRT is the C-runtime. Not everything is written in C.

The first version of the FT2 clone was released 7 years ago.

They didn't add PImpl support, they added std::indirect which can be used for PImpl among other things.

Impossible, Signal TUI is written in Rust.

> Windows users singling out Linux users for not catering to their platform. How the times change...

In my experience this was a problem over 25 years ago when I developed for Solaris and other non-Linux operating systems.

If you put both handlers in the same 256 byte page you can get away with only updating the low byte of the address.

Why an extra DLL instead of just patching the game executable? With some luck it is a one byte patch (from push 0 to push 4).

I find that this can reduce overall complexity. It makes it possible to use objects that can not be copied (such as a file descriptor wrapper) and moving can in most cases not fail. Without move semantics you'd have to use smart pointers to get similar results but with extra overhead.

I'm aware of how they are used, but fundamentally there is nothing with the words "array" and "vector" that says that one has a fixed size and the other has a dynamic size. If anything, it should be the other way around. Using the name vector for dynamic arrays is annoying when doing any kind of math coding. Even the designer of STL says the name was a mistake.

I find the short type names for integers and float hard to read. Somehow the size of the type is more important than if it is a signed integer, unsigned integer or a floating point number.

Using Vec for arrays is also annoying, repeating the mistake from C++.

RobWords made a video about it a few weeks ago! https://youtu.be/UAT-eOzeY4M

You should take a look at the presentation I mentioned elsewhere in this thread. You also have to keep in mind that it's not only the branches that use space, but also the error handling code. Code which must be duplicated for every single call to a particular function.

The CPU can not remember an infinite number of branches. Also, many branches will increase code size. With exceptions the unwind tables and unwind code can be placed elsewhere and not take up valuable L1 cache.

That's a different type of overhead than having unwind tables. With exceptions you wouldn't need a branch after each function call at all.

There was an interesting talk about C++ exceptions in smaller firmware at CppCon last year: https://youtu.be/bY2FlayomlE

Basically, the overhead of exceptions is probably less than handling the same errors manually in any non-trivial program.

Also, it's not like these table doesn't exist in other languages. Both Rust and Go have to unwind.

I'm not sure about other compilers, but compiling C code as C++ with MSVC ends up with pretty much the exact same code, instruction by instruction. C++ is a bit more strict though especially with casting, so a lot of code won't compile out of the box.

I do not find the Retrotink 4k any less configurable than the OSSC (non-pro, I haven't tried the pro). Note that the 4k is nothing like the 5X-Pro which is more plug and play.

I've been using the OSSC to upscale a 50 Hz RGB signal (SCART) to 1024x1024 (256 lines duplicated 4x). Both my HDMI capture cards happily accept that resolution with the right software.

I haven't tried the OSSC Pro, but the Retrotink 4k should probably also work fine and is really easy to use. A bit on the expensive side though...

The compiler can optimize this. See https://gcc.godbolt.org/z/hxW7hhrd7

  #include <cstdint>
  uint32_t read_le_uint32(const uint8_t* p)
  {
      return p[0] | (p[1] << 8) | (p[2] << 16) | (p[3] << 24);
  }

ends up as

  read_le_uint32(unsigned char const*):
          mov     eax, dword ptr [rdi]
          ret

This works with Clang and gcc on x86_64 (but not with MSVC).

I guess Ethereal is available :)

I put my CPU code up here: https://github.com/neonz80/shallenge-x86 . It requires an x86 CPU with the SHA256 extension.

It manages 1.1 GH/s on an Intel i7-13700K.

You can probably get a 2x speedup by shortening the string so that it fits in one block.

I'm a bit late to the game, but I managed to squeeze out about 1 GH/s on an i7-13700K.