Holger Spielmann wrote:
This procedure, to schedule file replacements for the next reboot, really seems brain-damaged to me. It looks like an ugly work-around.
Yep. That's typically Windows. It's full of these little surprises that work just a little different but require ugly work-arounds.
It could imagine that it would be better to modify the EXE loader in Windows (and DLLs are EXE to Windows AFAIR) to copy the executable to a special location hidden to applications and users first and execute it from there. Sure, we would lose a lot of performance doing it that way, but OTOH this would make Windows behave like I expect it from experience with usual OSes like SunOS or Linux. And, we will not run into problems after an update, like it has to expected when a new EXE requires a changed data or config file format which isn't compatible to the old version.
I must say it's an interesting approach, but I think we should not aim too high.
Windows has been built with a different phylosophy. Everything has been built with the idea that if it works most of the time, it's good enough. Take the whole dll handling, for example. There's still no good versioning system, including for dlls written by 3d party hardware manufucturers that are running in kernel mode.
What did they come up with?Same old story. Ugly workarounds that in this case require signing of dlls, implemented with some dark magic that seems to keep older versions around, somewhere. I don't even want to know the rest.
There is no way you can change that sloppy attitude.I am pretty sure that the Windows platform as it is today is nearing it's end, especially if alternatives become better and better. You can't just go on placing one workaround on the other without running into serious management, stability and/or security problems.
All we need to do, in my view, is offer a way out of the Windows platform by playing embrace&extend. The goal is to have developers that are interested in porting their app to other platforms use our environment as much as possible, no matter if they develop free of proprietary software. Developers should be able to install debian-w32 next to their normal environment and find not only development tools, but also a superior distribution system that enables them to distribute their software cross platform and very efficiently.
Users should be able to use just apt/dpkg to access native win32 ports of for example Gimp, Mozilla, etc. without having to install a whole Debian subsystem. The idea would be that once a user discovers the wonders of apt, he will use that more and more and thus favoring software within apt over the old&ugly setup.exe manual download method, which would give free software a competitive advantage. Imagine the face of user that has just discovered the networking capabilities of X, for example.
That way, users (and developers) can gradually enter the world of Debian in their own pace, so that eventually the Win32 platform will be nothing more then a Unix platform of reasonable quality but good support for legacy software.
At that point, there should still be some reasons to switch to a real Unix platform, so we shouldn't make the win32 port too good ...
Therefore, I think on win32 ugly workarounds are perfectly good, as long as they don't pollute the source code.
-- Arend --