win32 port

[Timothee Besset]

How bad do you want the win32 port? Having a win32 version sounds like an
awful lot of work and constraints. Some parts may be common, but in the
end the shells scripts that work in the linux/bsd/unix world won't work
for the win32 version of your setup etc. The UI probably can't be ncurses
or gtk, native .. or at best wxWindows?

I think throwing in a proprietary script language to perform common
operations would quickly be required for win32 operation, this pushes
even more things on the TODO list.

If you look at the GtkRadiant setup on win32, we are doing some freaky
stuff to the Install Shield setups, basically we work from templates and
generate setups on demand (with a selection of the game packs to include).
Building something that could actually compete with the existing setup
solutions on win32 would be an enormous work. And I don't think it should
be in the objectives.

On the other hand, the idea of a portable installer/update system .. and a
custom GUI code that works on all platforms (read 'Doom-engine setup UI')
IS sexy.

TTimo

On 23 Nov 2002 03:59:40 -0800
Stéphane Peter <megastep at megastep.org> wrote:

> Some interesting ideas from TTimo. See my comments below.
> 
> One thing I'd like to add though regarding portability is that it would
> be nice if sometime in the future we are able to build a Win32 version
> of setup. Which means that we should have a way to get rid of all the
> Unixisms and other assumptions in the current code (things as simple as
> / vs \ for directory separators, or the more general reliance on shell
> scripting).
> 
> Just something I think we should keep in mind...
> 
> Le sam 23/11/2002 à 03:17, Timothee Besset a écrit :
> > I love designing new apps. You can have plenty of cool ideas and then
> > decide to drop them because it will be too complicated. So here are my
> > thoughts:
> > 
> > - Multiple UIs .. anyone using the SuSE distribution? The yast
> > configuration tool has text and qt uis .. pretty much what setup 1.x is
> > doing. Very good stuff.
> 
> I have seen it in action... Isn't that part of YaST which is proprietary
> though ?
> 
> > - Is the XML description generic enough to describe the installations? Do
> > we need some flow control? (if-then-else?)
> 
> That sounds like a good idea - this would also partly remove the need
> for some things otherwise achieved through shell scripts.
> 
> > - Usage of shell scripts: in 1.x we often drop in shell scripts to perform
> > some operations. Are those reliable and portable enough? Would LUA be any
> > help?
> 
> That would be a problem for non-Unix platforms (i.e. Win32). Although I
> suppose we could always ship a small bash.exe to run these with setup
> ;-). Other scripting languages could be an option, assuming they are
> also portable and allow to do the same kind of tricks as in regular
> shell scripting: Also a fall-back to the native shell should be allowed,
> IMHO.
> 
> > - Support 'on-demand' download? i.e. download a small stub package, find
> > mirrors to get further elements? I think that's what loki_update does,
> > setup and update should be more interdependent?
> 
> Like the Ximian installer then ? At first I am thinking this could be
> done separately from the core installer package (maybe as an add-on of
> some sort).
> 
> > - Local caching of the setup UI code? The size of UI-related binaries is
> > pretty big in setup packages. Could we have the UI stored in a local cache
> > (~/.lokisetup/ui/<API-version-GUID>/)? This would be working with
> > 'on-demand' setups. You launch a query program to some XMLized URL, it
> > checks if you have the correct UI stuff already and starts downloading?
> 
> Setup 1.x already does something remotely similar for the uninstall
> program. It is usually copied over to the user's
> ~/.loki/installed/bin/... hierarchy of directories, and the binary there
> is used if no other 'loki_uninstall' binaries are available.
> 
> There is the problem that if you have for instance a NFS shared home
> directory, you would need to have cached binaries for all the
> architectures you are using. Maybe this all thing could be part of the
> add-on package I was mentioning above.
> 
> IMHO this raises the more important question of binary modularity. This
> implies that there would be actual UI backend modules of some sort. So
> how would they communicate with the installer core ? Shared .so/.dll's ?
> Separate programs communicating with some kind of IPC ? I am kind of
> hesitant on this issue given the relatively small sizes of such modules
> compared to the core installer (especially if we get modularization
> right this time).
> 
> > TTimo
> 
> -- 
> Stephane Peter
> Sr. Software Engineer
> Codehost, Inc.
> 
>