String Safety

[mh]

Windows 95 had to run in 4mb I believe, although I've never known anyone successfully do so. I did see it running in 8mb once and it was horrible.

The main flaws with Windows 95 were a combination of design decisions made to squeeze it into this tiny space, it's DOS heritage, maintaining an extremely high level of backwards compatibility, and the way it mixed 16-bit and 32-bit code. Much of these were valid design decisions or for reasons that were correct at the time, but that doesn't mean that they're still valid or correct today. Many of the (oh so true) criticisms of Windows from the Unix side were based on this stuff, and completely disappeared with NT-based versions (many in the Unix side seem unaware of this and still rely on outdated criticisms).

Windows 98 was an over-engineered follow-on that added lots of extra stuff on top but didn't do much (if anything) to fix some of the glaring problems underneath. FAT32 and USB support were good to have though. I think history will show it as more a stringing-out of the old DOS-based Windows line than a viable product in it's own right (definitely true with ME); if MS had been ready with an NT5 version that was suitable for home use at the time, or even a little later, it may have never even existed.

DOS-based Windows was effectively already dead by the time Windows 95 was released. NT had existed for some years, and was clearly superior in just so many ways.

[Spike]

fat32 and usb were in win95b. perhaps not many class drivers, but enough to get a usable system hence the prevelence of non-class devices at the time.
from my experience win95's bugs were generally fairly predictable. win98 always seemed so random when it crashed.
active desktop and pretty window titlebars are the only two things win98 really offered over 95...

[mh]

I'd forgotten about 95b.

You could also get a large chunk of the 98 experience by installing IE4 on 95; all the extra desktop gunk and all the random crashes, heavy page-file usage and other nonsense.

My favourite was the way the OS used to blue-screen if you ejected a CD while it was still being read.

[revelator]

actually 95 could run on 2 mb but you needed to trick the installer unless you ran the install on a seperate machine. it was massively slow though and only bearable with the use of memory compression tools like QEMM.
and aye usb support allready came with 95 in my case i got it with the OSR2 version. though XP couldnt handle a lot of dos based games out of the box i could usually trick them into running by using tools like VDM sound etc.
still got my old WTF PC i used to pull a trick on peeps back then with, it was built into a massive case from an 286 but was actually an overclocked celeron 300A. usually this cpu ran at 300 mhz but i managed to overclock it to 600 so 100% OC
it still runs btw hehe. back then this beast could outrun even very expensive machines so thats where the WTF came from

[revelator]

[qbism]

[revelator]

yep easiest way to get around it mine might have its uses though as it can be expanded.

[Knightmare]

[revelator]

tbh it shouldnt be nessesary to use our own library replacements for anything but strlcpy and strlcat if using msvc > 2003 since those allready have str safe functions.
it would require a few defines to check for recent msvc but in the end it would make the source smaller.

_vsnprintf is an edge case though as the msvc and mingw64 ones returns bogus output (i know from git and several other sources that its broken).
_snprintf is also affected.
the bsd function i posted above returns the correct output and is used in the beforementioned sources.
strlcpy and strlcat might not even be nessesary either with strncpy_s and strncat_s.

[revelator]

Let me explain as good as i can why _vsnprintf and _snprintf are broken on windows.
on error _vsnprintf returns -1 where it should return the number of bytes it could have written to dest.
same goes for _snprintf.
Mingw has a vsnprintf that returns the correct value (notice the lack of _ in front of the name).
Mingw also has a snprintf which returns the correct value.
Msvc lacks those so to get the correct output we need to roll our own versions as return -1 triggers a fault (yep i actually tested this).
Mingw also has the _vsnprintf function with the same bug as msvc so do not use this version instead use the one without the _.

I can provide test code so you can see for yourself

[Knightmare]

[mh]

[revelator]

this was not found by me but by the texlive and git creators.
if the value returned was actually just a negative number it wouldnt have mattered but it translates to 'bogus value' in msvc syntax and triggers a fault because the functions need to know the size it could have allocated even if the string is empty.

part of the patch with comments from the git folks.

+# Define SNPRINTF_RETURNS_BOGUS if your are on a system which snprintf()
+# returns -1 instead of number of characters which would have been written
+# to the final string if enough space had been available.
+#
+# Define VSNPRINTF_RETURNS_BOGUS if your are on a system which vsnprintf()
+# returns -1 instead of number of characters which would have been written
+# to the final string if enough space had been available.
+#

the above applies to msvc/mingw64/mac and a few other obscure systems where it returns -1 the edge case here is mingw which has a vsnprintf without the _ in front which works.
i tried with both just for fun using C::B + mingw and _vsnprintf crashes kernel32.dll while vsnprintf works as expected. mingw64 does not have the vsnprintf function from mingw so it also goes bad :S

[revelator]

[Knightmare]