71–80 of 119 posts
Unless I'm mistaken, this seems to be the original programmer on youtube: Dave's Garage - Secret History of Windows ZIPFolders https://youtu.be/aQUtUQ_L8Yk
As noted in the blog post, he's the author of the Shell Namespace code, but not the ZIP code beneath.
Earlier quoted context omitted.
I never tried cutting from CD-RW, but AFAIR each burning would append a non-trivial header (like 20MBs or so) so that would be a pretty expensive thing to do :) AFAIR when you "copied" into CD-RW the files would show up semi-transparent (pending) and you'd have to click a button to process with burning. Probably same for cutting I guess.
Speaking of old Windows and CDs, Windows had some crazy trick to turn CD-R ( not CD-RW) into rewriteable medium. I'm guessing they simulated a regular file system on top of an append-only representation. I never dug into the details back in the day, because I never used this feature. Unfortunately, IIRC, this trickery was enabled by default when copying files to CDs - which was a problem, because nothing else could r…
Earlier quoted context omitted.
Yes. Functional world is not impervious to leaky abstractions. I am personally of the opinion that, to be a good developer, you have to have mental model of what happens beneath. If you are programming in a high level language it is easy to try forget about the fact that your program runs on real hardware. I know, because I work mostly on Java projects and trying to talk to Java developers about real hardware is usel…
> Most don't know what virtual memory is or are surprised that two processes can resolve different values under same pointer. Yikes. How many of them have a degree in computer science?
What happens is they know what virtual memory is but can't connect the concepts. It is knowledge without understanding.
Earlier quoted context omitted.
Oh boy. I was thinking USB 2.0 is main reason for Android Windows copying of photos to suck so much, but the rabbit hole is much deeper. It's sad that with cloud being the solution for everything those days, this will probably never be improved within next decade.
It's ridiculously wasteful and slow to have to upload to a cloud server who-knows-where, then download it again to the computer several feet away. Yet with Android having removed USB mass storage, that's often the easiest way. It's against the interests of those who profit off selling cloud storage to make local transfers easy.
Earlier quoted context omitted.
I never tried cutting from CD-RW, but AFAIR each burning would append a non-trivial header (like 20MBs or so) so that would be a pretty expensive thing to do :) AFAIR when you "copied" into CD-RW the files would show up semi-transparent (pending) and you'd have to click a button to process with burning. Probably same for cutting I guess.
Speaking of old Windows and CDs, Windows had some crazy trick to turn CD-R ( not CD-RW) into rewriteable medium. I'm guessing they simulated a regular file system on top of an append-only representation. I never dug into the details back in the day, because I never used this feature. Unfortunately, IIRC, this trickery was enabled by default when copying files to CDs - which was a problem, because nothing else could r…
25 years without major bugs and still being extremely useful is a complete win in my book! This is definitely a bug, but I wonder if Microsoft will think it's worth it to even update it, it doesn't seem like it happens enough to cause widespread issues.
Earlier quoted context omitted.
Yes. Functional world is not impervious to leaky abstractions. I am personally of the opinion that, to be a good developer, you have to have mental model of what happens beneath. If you are programming in a high level language it is easy to try forget about the fact that your program runs on real hardware. I know, because I work mostly on Java projects and trying to talk to Java developers about real hardware is usel…
The funny thing is that in the old days, it is required to know how the machine worked - you coded assembly against physical memory. But that was incredibly hard, and error prone (and comes with tonnes of limitations). The fact that today, it's very easily possible to write working programs without knowing any of the underlying details, is a marvel. If i were to hire a truck driver, i wouldn't expect to have to ask h…
No, it wasn't. If it was incredible anything it was tedious. But nobody really expected anything super complex from you. Just look at the kinds of programs that were produced in 80s or 90s.
It would be incredibly hard today. Machines got very complex, operating systems got very complex.
But it wasn't so complex in 90s. I think I stopped writing assembly when I started using WINAPI because that was the point when assembly stopped being practical.
Sometimes I wonder how I would fare if I was 18yo again today and had to start in development and learn everything from scratch. I feel being able to learn everything as the technologies were evolving is a huge advantage I enjoy.
Earlier quoted context omitted.
> The popular, naive implementation is, as above, to repeat same simple operation over and over again: read from source, write to destination, read from source, write to destination. Reminds me of the kind of patterns functional programming languages introduce, where you process data by describing operations on individual items and assembling them into "a stream". I'm always wary of those - without a good implementat…
Rust for example does indeed apply lots of black compiler magic to really cut the cost of those abstractions (I've seen the output of complex iterator chains compiled down to exactly the same machine code you'd write without the abstractions). However man is it slow to compile. Pick your poison.
I pick Rust every time.
I have this concept of easy problems and hard problems. Every decision to choose technology is a compromise and comes with its own problems. It is your job to know whether these are easy or hard problems.
Compilation time is easy problem. Just put more hardware to it or modularize your application or schedule your coffee breaks correctly.
Building reliable abstractions to prevent hard to debug problems is hard problem. Building a large, complex, reliable application in ANSI C is hard problem.
I try imagine, what would you rather spend your time on: coffee breaks or debugging complex bugs?
Earlier quoted context omitted.
It's ridiculously wasteful and slow to have to upload to a cloud server who-knows-where, then download it again to the computer several feet away. Yet with Android having removed USB mass storage, that's often the easiest way. It's against the interests of those who profit off selling cloud storage to make local transfers easy.
If I need to move a lot of data I just use adb and USB debugging to access the files. That is actually fast, but it's ridiculous that I have to do it.
Having written a shell namespace extension, I now use the concept as a great example of making the wrong abstraction interestingly enough. Shell namespaces are a odd win32 concept rather than a filesystem concept and cause a lot of headaches (read support calls) when people see that they work in explorer, but not from arbitrary applications depending on how they use the underlying APIs. If you're trying to abstract t…
Of course, as you point out the right abstraction in many cases is an abstract filesystem, and for whatever reason pluggable filesystems aren't really a Windows Thing (though I think they may have been added recently for features like OneDrive and lazy git checkouts). The existence of shell namespace extensions probably stopped that valuable feature from getting put in...