Nice touch making this video 255 seconds long

Just one correction: It's not about older systems being unable to handle larger numbers. Even the oldest 8-bit processors had instructions to work with arbitrarily long numbers. You can easily add two 128-bit numbers on a C64, for example. It just takes a bit longer, as you have to chain 16 8-bit operations. Also, Windows never ran on 8-bit systems; the PC even started out with a 16-bit processor. The reason was speed and memory usage (both RAM and on disk). Moving around data takes time, and the slower a processor is, the more time you can save by limiting the amount of data you have to move. It also takes up space. If you want to read the name of a file into memory, you need to reserve enough memory to hold the full name. Just imagine a current computer having to be able to show a filename that takes up 4 GB---it could do it, but taking up a quarter of your RAM to store a single filename would be really stupid. The same goes for storage media. The PC started out with a 160kB floppy disk drive. Who would suggest allowing filenames of up to 32kB (the current Windows limit) on that? Save 5 files on that, and it's full with just the filenames... Same goes for other limits. The 4 GB file size limit comes from storing the size of a file in 4 bytes. Nobody wanted to waste double the storage space or spend the extra CPU time handling a larger number when 4 GB was a magnitude larger than the size of harddrives... Sorry for the rant, but too many programmers have lost any sense of the cost of data storage. So much software could run twice as fast if its programmers had limited the size of their memory storage so more of t he regularly accessed data fit into the CPU cache. But RAM is aplenty nowadays, so spreading your data out over 1 or 2 GB of RAM doesn't seem to matter. But accessing RAM still takes time, and even more if it isn't cached on the CPU. Allocating a 256-byte buffer instead of a 32kB buffer still makes sense nowadays.

@NickMaltbie

Жыл бұрын

Thanks for the detailed response, this has a lot of information I didn’t know about some older systems. I work with data center network coding for day job so we have to consider lots of optimization! Ha, I guess the video is somewhat misleading the. It is for backwards compatibility but the reason the old limit was 256 wasn’t due to the computing power of the system as a limit but for efficiency. It’s an important distinction to make when working with computers.

@HenryLoenwind

Жыл бұрын

@@NickMaltbie Indeed, the distinction between "it can't", "it can, but it would be really slow", and "it can, but if everything was done that inefficiently, the system would be really slow" often gets overlooked. Especially the latter one is a bit of a pet peeve of mine, having done enough coding for the game loop---when everything has to fit into one 20th of a second, those small wasteful things add up quickly.

@NickMaltbie

Жыл бұрын

@@HenryLoenwind thankfully modern compilers can help fix a lot of the optimization problems, but still good to optimize when needed!

Also why max # of rupees in the original Zelda was 255! I always thought this was so random when I was a kid, then had a huge light bulb moment years later (and once you see the "255" you'll start noticing it pop in other places in software, esp. other old gaming examples).

Its strange. I've encountered this error when updating a backup on one of my external storage drives but not the others, 1/3. One storage drive is inside my system and the other two are external. Oddly, I only encountered the error when moving the same files to the second external drive. All three drives aside from their drive letter and a short drive name, they share the same drive paths within a "backup" folder and are formatted in NTFS. Have any ideas why this error shows when copying to the second external but not to the first external? Aside from the registry entry, drive formatting or file path length, is there something else that can restrict this based on drive?

@NickMaltbie

2 жыл бұрын

It’s actually a windows limitation not an NTFS problem. Sometimes windows is weird with how it interacts with external drives. Try using the prefix “\\?\”. Before the drive name to override the limit and allow a 32k character limit in file name length. Also, individual names within the path may have a limit of 256 characters despite a 32k overall limit. Try backing up the files and reformatting the drive then coping back the files. Hope this solution helps :)

fun fact: The programmer day is the 256 of the year

Windows 10 added "Long Path" support but it's not enabled by default. I'd avoid such long filenames as moving the files across computers and storing them into compressed containers will be a can of worms.

@NickMaltbie

Ай бұрын

Hehe. Yeah, weird that haven’t enabled it by default.

Just found your channel from the last video you uploaded! Really enjoying the content. It's interesting and well made

@wunderburst6444

Жыл бұрын

Why test games

@NickMaltbie

Жыл бұрын

Thanks! I’m happy you like the content. I’m really enjoying working on the videos and hopefully can make more over the next few weeks.

@NickMaltbie

Жыл бұрын

Yep. That video went through too many re-writes and took way too long to finish. Need to just finish a draft and stick to it when working on videos!

2:55 theres an error: The bottom green part should say 0 x 1 instead of 1 x 1

@NickMaltbie

Жыл бұрын

Thanks for watching the video and catching the error! Maths hard. I think I corrected it in the next line but still an error.

FUN FACT: if the path to a file is too long, Windows shows the path in the UNC format instead of the standard one like "C:/users/someone/...". The UNC path format for files on a local disk is the same as the normal one, but it starts with "\\?\" before the full path.

Kind of a persnickety but DOS had a limit of 8 character with a 3 character extension.

My man is counting in binery in the top right

Nerd ‼️ Alert 🚨