The time the x86 emulator team found code so bad they fixed it during emulation

Post by jonathanlydall » Wed, Jun 17, 2026, 1:08 PM UTC

dgrunwald wrote: post #168

jonathanlydall wrote: post #128

Earlier quoted context omitted.

Its slowness is also a function of security software or any other file system "filters" (I believe they're called) are installed. For example, I run TortoiseGit which has a caching feature which is supposed to make it faster at showing what to commit. Disabling it increases the number of items I can delete per second in my Windows Explorer from about 1000 to about 3000 while making not making TortoiseGit operations m…

`rmdir /s /q` in a command prompt is significantly faster than Windows Explorer. Yes C: is slow due to filters and Dev Drive is faster; but this difference can only be felt when using the command line; Windows Explorer has so much additional overhead that the overhead from file filters is insignificant in comparison.

Post by quietbritishjim » Wed, Jun 17, 2026, 2:28 PM UTC

sumtechguy wrote: post #154

quietbritishjim wrote: post #104

Earlier quoted context omitted.

> asking for 1 byte 65536 times, is indeed different than asking for 65536 bytes, 1 time. Yes it's different. As others have noted, the difference is what is returned if less than 65536 are available to read in the file: total failure vs partial read. There is, unsurprisingly, no requirement that it has an unnecessarily inefficient implementation to meet this behavioral requirement. (The C standard doesn't talk about…

Also you need to be careful what you read/write. In some cases. As many examples out there use int/char etc to show how to use the thing. But if you switch to structs that fwrite can totally burn you if you use the sizeof call. As the sizeof a struct can vary between platforms and compilers. Depending on packing. Then endianness can sometimes mess you up. If you are reading/writing for yourself you can get away with…

Post by Joker_vD » Wed, Jun 17, 2026, 3:41 PM UTC

Someone wrote: post #174

Joker_vD wrote: post #170

Earlier quoted context omitted.

Shouldn't you be using cppreference.com instead of cplusplus.com? Because the former [0] actually has this language: Reads up to "count" objects into the array "buffer" from the given input stream "stream" as if by calling fgetc "size" times for each object, and storing the results, in the order obtained, into the successive positions of buffer, which is reinterpreted as an array of "unsigned char". This whole fread/…

Maybe, but that text says “as if” and even “If an error occurs, the resulting value of the file position indicator for the stream is indeterminate. If a partial element is read, its value is indeterminate.” so it doesn’t in any way require implementations to implement it by actually reading one byte at a time. That description also fits what I saw in the implementations I inspected, both of which simply try to read s…

    fread(ptr, size, count, iop)
    unsigned size, count;
    register char *ptr;
    register FILE *iop;
    {
        register c;
        unsigned ndone, s;
    
        ndone = 0;
        if (size)
        for (; ndone= 0)
                    *ptr++ = c;
                else
                    return(ndone);
            } while (--s);
        }
        return(ndone);
    }

    #define getc(p)  (--(p)->_cnt>=0? *(p)->_ptr++&0377:_filbuf(p))

Post by sidewndr46 » Thu, Jun 18, 2026, 3:19 AM UTC

account42 wrote: post #70

tester756 wrote: post #34

Earlier quoted context omitted.

Who's problem is this? Nvidia probably doesnt officially say anything about this and 99.9% of people do not rename process name

It's definitely Nvidia's problem if this breaks something. Nothing in the D3D/OpenGL specs says that you can (not) use certain executable names.

Post by sumtechguy » Mon, Jun 22, 2026, 1:06 PM UTC

quietbritishjim wrote: post #173

sumtechguy wrote: post #154

Earlier quoted context omitted.

Also you need to be careful what you read/write. In some cases. As many examples out there use int/char etc to show how to use the thing. But if you switch to structs that fwrite can totally burn you if you use the sizeof call. As the sizeof a struct can vary between platforms and compilers. Depending on packing. Then endianness can sometimes mess you up. If you are reading/writing for yourself you can get away with…

Are you sure you're not thinking of raw read() / write() (the operating systems calls) rather than fread() and fwrite() (the C standard library functions)? fread and fwrite already have a cache, so repeated calls won't make lots of OS calls. Or, at least, they shouldn't! Clearly OP's implementation was a counterexample (it made lots of OS calls just for a single fread call).