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 --
