4 ms·
> You could work around this by doing rename + delete instead of just delete. That's um, inconvenient. I've heard similar tales, but I'd wager there are many
by EdSharkey 13y ago
> You could work around this by doing rename + delete instead of just delete.
That's um, inconvenient. I've heard similar tales, but I'd wager there are many more corner cases that could bedevil us. For example, what about .dll's and .exe's that are currently open in other processes? My experience has been that you simply cannot do anything with those files once they have been opened.
The whole Windows file system just seems like a rat's nest of bad and worse design decisions.
> Granted that's a big if.
Stop. This is a bad design decision that has surely cost industry billions to reckon with and maybe cost a few lives along the way too. This is not the developer's fault.
> Yeah, I agree this was kind of stupid. There are internal folks at MS, some of them quite influential, who think it's stupid too. But it's already been done.
Hm, sounds like you're an insider! Right, well, I'm not satisfied with that blasé attitude. I think you ought to take more pride: Windows is kindof important, like, to humankind. It is really unethical to leave such bad designs in place, festering and impeding our progress and wasting our time. Your internal folks at MS who are clueful need to be heard.
> > Trash the standard Windows API (not just hide it)
>
> This is the same fallacy a bunch of internal people came up with in Windows 8, however the truth is large chunks of the Windows API have nothing wrong with it.
Seems to me that Windows RT could run on any kernel or VM. If that's the direction all development is going to take at MSFT, then do everyone a favor and chuck that boat anchor Win32 and plop the legacy apps into a VM ghetto running in seamless mode.
Don't be afraid, just do the needful.
- asveikau 13y ago> Hm, sounds like you're an insider! Was. As the comment you're replying to mentions in parenthesis, I wasn't there for all that long and I left a few years ago. Not that I in my lowly position would have been able to convince people to change some of this stuff... > Seems to me that Windows RT could run on any kernel or VM It's pretty heavily tied to Win32 and COM. I think the way you're talking about it is a little weird though. Would you criticize Android, for example, for having a Unix-like system underneath? I mean, 'cause Unix is like.. old, and stuff. </snark> Stuff simply being old isn't really a compelling reason to discard it. I'd say NT especially is mostly on the right track in terms of being a modern kernel. Not without its warts but it doesn't deserve comparison with DOS or 9x. COM has some good ideas at its core too.
- EdSharkey 13y ago> It's pretty heavily tied to Win32 and COM. Ah, I did not know that. So, is WinRT a peer to Win32/Win64, or is it built atop Win32/Win64? I have heard that COM is bread and butter to the way Microsoft teams compose their systems, I should have known they would have based it on that. Maintaining the legacy through COM seems to encourage coupling in the design that would make it impossible to change out the OS underpinnings. > I'd say NT especially is mostly on the right track in terms of being a modern kernel. In the abstract, yes, NT is a vision of pure loveliness. NT 3.5 was super exciting when it came out, such a rock solid business OS (at the time)! Not sure what we got now in the concrete sense though - it's a real hodgepodge, new and old. I sense all the wise greybeards who could provide the vision have long since moved on. I'm not suggesting Unix-like is a panacea, but it's on a better path than Windows as far as file systems go. There are surely optimizations and streamlining that a new design could showcase to blow away Unix/Linux/BSD. A new design from Microsoft would be refreshing, mainly because they have the cash and power to do it right and still offer their all-important backwards compatibility.