Re: setup.exe sucks
Christopher Faylor wrote: I'm not as concerned about the package management as I am about the UI, actually. If we don't have a good UI for initial install, then the initial user experience is still going to be painful. You may want to take a look at my pre-release RPM distribution I did back in July 2001. Although dated, the U/I looks like a native Win32 app; I used Tcl/Tk to write the installer logic and the GUI. IIRC, the entire installer was around 200-300 lines of Tcl. (I can post the CD .iso if you want to download it.) FWIW, I agree with with Warren Young; the next installer should be written in a scripting language. Besides the source line count that Warren mentions, the other benefit of using a scripting language is that it allows casual programmers (i.e. those with little or no Cygwin or Win32 programming experience under their belt) to make changes and bugfixes easily, with little to no handholding. A compiled program does not provide the same benefit. -- D.
Re: setup.exe sucks
You do have to have something early on that bootstraps what you need, like setup.exe does now, but it could always install the cygwin first before it does anything. Yes, once we had yum, we could almost have the unattended install working. Of course, you couldn't use yum to install python or cygwin, as it stands right now. So this idea just came to me and seems brilliant right now, but may not be: what about making setup.exe do nothing except install a bootstrap Cygwin including python and rpm database. After that yum or apt-rpm or connectiva's thing would to the rest. I see the advantages being: throw out the most confusing parts of setup, but keep around a lot of bootstrap work. There would not need to be any changes to the basic Cygwin install instructions (the Use setup.exe mantra). The existing problems with using Unix-based tools on Windows like replacing files would remain, though.
RE: setup.exe sucks
Warren Young wrote: Rebooting is a cop-out in this case. All the setup program has to do is stop running services before starting the upgrade. I didn't mean to imply that rebooting was the best solution, just that there may be some extra steps involved when you do the base Cygwin install. Other things that come to mind are making sure that mount points and accounts are set up. This could be done as a separate step that does whatever it needs to do in order to prepare for the package installer and then kicks off the package installer. The package installer could then be a regular Cygwin application. This would also make it easier to replace the package installer component in the future. -Jerry
RE: setup.exe sucks
One issue that sometimes pops up currently is the failure of post-install scripts when Cygwin's DLL is being replaced. I know that you can run into trouble if a daemon is currently using the DLL when you update the cygwin package, at least. Perhaps a two-part install wouldn't be that bad, as long as the base Cygwin installer automatically kicks off the package updater and the package updater can kick off the base Cygwin installer when needed/requested. The base Cygwin installer could then be done using MSI or whatever and could initiate reboots/etc. as needed before starting the package updater. gsw
Re: setup.exe sucks
Williams, Gerald S (Jerry) wrote: installer when needed/requested. The base Cygwin installer could then be done using MSI or whatever and could initiate reboots/etc. as needed before starting the package updater. Rebooting is a cop-out in this case. All the setup program has to do is stop running services before starting the upgrade. This gets me into a different subject: one of the things that is more difficult about Cygwin than it has to be is that you have to run command-line scripts to set up services like sshd. If the installer could manage this, even if only to start a Cygwin window running the script, that would be helpful. A side benefit of this is that the service names would thereby be standardized, which would then let the installer search the service set for those that should be stopped before upgrading. This only applies to the NT-based kernel case, of course. I wouldn't care if the installer had to reboot the system for 9x kernels. I do like the idea of writing the next version in some kind of scripting language. It allows more features per line of code, so more features get written in a given amount of programmer time. The trick, of course, is how to bootstrap the scripting environment on the first install. Probably a real Windows installer could manage this, using a temporary private version of cygwin.dll to run the scripting environment.
Re: setup.exe sucks
Warren Young wrote: stop running services before starting the upgrade. Thinking more about it, couldn't you just call LoadLibrary() on the full path to cygwin.dll, and if that succeeds, get the process list from it and send out kill signals? If LoadLibrary() doesn't succeed, either Cygwin isn't installed, or the DLL has gone missing; in either case, you can probably upgrade without a reboot anyway.
Re: setup.exe sucks
On Thu, Dec 09, 2004 at 05:25:09PM -0700, Warren Young wrote:
Warren Young wrote:
stop running services before starting the upgrade.
Thinking more about it, couldn't you just call LoadLibrary() on the
full path to cygwin.dll, and if that succeeds, get the process list
from it and send out kill signals?
Time for another sigh: Sigh.
You can't use LoadLibrary with cygwin and I really wasn't suggesting that
we modify the DLL or introduce new functionality to accommodate setup.
That said, however, you could iterate over all of the running processes
and find out which was using cygwin1.dll. You don't need cygwin for
that.
In fact, I was just playing around with some source code to do this
yesterday. It is attached, for the curious.
cgf
#include windows.h
#include ntdll.h
#include tlhelp32.h
#include stdio.h
#include psapi.h
static void snap (DWORD pid)
{
HANDLE h = CreateToolhelp32Snapshot (TH32CS_SNAPMODULE, pid);
MODULEENTRY32 m;
printf (+PID %u\n, pid);
m.dwSize = sizeof (m);
while (Module32Next (h, m)) {
printf (%s\n, m.szExePath);
}
CloseHandle (h);
}
static void nt (DWORD pid)
{
HMODULE hMods[1024];
DWORD cb;
HANDLE h = OpenProcess (PROCESS_QUERY_INFORMATION | PROCESS_VM_READ,
FALSE, pid);
printf (-PID %u\n, pid);
if (EnumProcessModules(h, hMods, sizeof (hMods), cb)) {
for (int i = 0; i (cb / sizeof (hMods[0])); i++) {
char path[MAX_PATH+1];
if (GetModuleFileNameEx (h, hMods[i], path, sizeof(path)))
puts (path);
}
}
CloseHandle (h);
}
int
main (int argc, char **argv)
{
bool alt = 0;
if (*argv[1] == '-') {
alt = 1;
argv++;
}
while (*++argv) {
DWORD pid = atoi (*argv);
if (!alt)
snap (pid);
else
nt (pid);
}
exit (0);
}
Re: setup.exe sucks
On Thu, 9 Dec 2004, Christopher Faylor wrote: On Thu, Dec 09, 2004 at 05:25:09PM -0700, Warren Young wrote: Warren Young wrote: stop running services before starting the upgrade. Thinking more about it, couldn't you just call LoadLibrary() on the full path to cygwin.dll, and if that succeeds, get the process list from it and send out kill signals? Time for another sigh: Sigh. You can't use LoadLibrary with cygwin and I really wasn't suggesting that we modify the DLL or introduce new functionality to accommodate setup. That said, however, you could iterate over all of the running processes and find out which was using cygwin1.dll. You don't need cygwin for that. In fact, I was just playing around with some source code to do this yesterday. It is attached, for the curious. cgf I may be barking up the wrong tree, but I seem to recall complaints that code like this may hang when certain types of firewall/anti-virus software are used. It also may require administrative privileges on the machine. As time permits, I'll try to dig up evidence to either confirm or contradict this. Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! The Sun will pass between the Earth and the Moon tonight for a total Lunar eclipse... -- WCBS Radio Newsbrief, Oct 27 2004, 12:01 pm EDT
Re: setup.exe sucks
On Tue, 2004-12-07 at 15:16 -0500, Christopher Faylor wrote: I believe that it was always Robert's intention to work towards the use of a true package manager someday. That time is now. I can't take it anymore. Ack. Rob -- GPG key available at: http://www.robertcollins.net/keys.txt. signature.asc Description: This is a digitally signed message part
Re: setup.exe sucks
BTW: There is new Conectiva packager, which should be the best, and builds out of the box. http://zorked.net/smart/FAQ.html Requires python. Works with .rpm, .deb and pkgtool files and up2date- and Conectiva-style mirror description formats. I don't like python that much, but I try how to convert our format easily into rpm or deb and how hard it would be to add a wxpython interface. gtk already exists. ./setup.py build ./setup.py install smart install --help smart channel --help -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/
Re: setup.exe sucks
On Wed, Dec 08, 2004 at 02:52:30PM +0100, Reini Urban wrote: BTW: There is new Conectiva packager, which should be the best, and builds out of the box. http://zorked.net/smart/FAQ.html Requires python. Works with .rpm, .deb and pkgtool files and up2date- and Conectiva-style mirror description formats. Yes, I saw that. I didn't know that it built OOTB on cygwin. Interesting. I don't like python that much, but I try how to convert our format easily into rpm or deb and how hard it would be to add a wxpython interface. gtk already exists. Converting the tar.bz2 files to rpm files would not be that hard. It should be automatable. I'm willing to do that work. I'm not as concerned about the package management as I am about the UI, actually. If we don't have a good UI for initial install, then the initial user experience is still going to be painful. cgf
Re: setup.exe sucks
Christopher Faylor schrieb: On Wed, Dec 08, 2004 at 02:52:30PM +0100, Reini Urban wrote: BTW: There is new Conectiva packager, which should be the best, and builds out of the box. http://zorked.net/smart/FAQ.html Requires python. Works with .rpm, .deb and pkgtool files and up2date- and Conectiva-style mirror description formats. Yes, I saw that. I didn't know that it built OOTB on cygwin. Interesting. I don't like python that much, but I try how to convert our format easily into rpm or deb and how hard it would be to add a wxpython interface. gtk already exists. Converting the tar.bz2 files to rpm files would not be that hard. It should be automatable. I'm willing to do that work. I'm not as concerned about the package management as I am about the UI, actually. If we don't have a good UI for initial install, then the initial user experience is still going to be painful. Agreed. And since there will be no linux UI packager which will work on Win32-Native also (unless some wxwindows or tk UI appears) someone will have to bite into the dust and add a win32 native lib to such an UI. Most just use gtk nowadays. Smart seems to be the best so far. But maybe it's too early. Released two days ago :) -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/
Re: setup.exe sucks
Christopher Faylor schrieb: As loath as I am to admit it, I think that setup.exe should be scrapped in favor of one of the other setup projects out there. We just aren't doing a good job of keeping up in the innovation or the tech support department. I know the reasons that all of the above exist and I TRULY am not blaming anyone for this state of affairs. I think it is just time to call an end to this program which everyone seems to struggle with and work on providing something better. People have previously offered other suggestions for setup utilities. Does anyone have a favorite program that they think would be useful for the cygwin project? setup.exe doesn't suck that much. Just the memory footprint sucks, the UI partly sucks, and update cycles suck. I investigated what other existing packagers do, and how we can use it. I started working on a complete new rewrite, based on some scripting language, not c++. (easier maintainence and faster development) Based on some existing packager. We have the only packager not written in a higher level language. * perl Win32::GUI packaged via par to one single exe for example. mandrake drakex as base. Just the abstract GUI layer for Win32::GUI has to be added. Tk and console backends currently exist. Or maybe tk-native. will get 3MB * wxpython compiled to one single exe: Any python installer as base, like yast. ~7MB * some lisp based UI packager: Currently my favorite. Easiest to write and maintain for single person. ~2MB * some php-winbinder UI. ~2MB * some dhtml or java based packager. A webbrowser as requirement should be reasonable. very small * suneido: This would be very easy to write and maintain. A packager is some kind of hello world for suneido, but it would get too large. And it's an orchid language. ~1MB exe and db (which may contain the app also) downloaded on demand. The main problem are our requirements, that it must be a native windows app, with single-click download/open without any interim installer. -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/
Re: setup.exe sucks
On Tue, Dec 07, 2004 at 08:58:41PM +0100, Reini Urban wrote: Christopher Faylor schrieb: As loath as I am to admit it, I think that setup.exe should be scrapped in favor of one of the other setup projects out there. We just aren't doing a good job of keeping up in the innovation or the tech support department. I know the reasons that all of the above exist and I TRULY am not blaming anyone for this state of affairs. I think it is just time to call an end to this program which everyone seems to struggle with and work on providing something better. People have previously offered other suggestions for setup utilities. Does anyone have a favorite program that they think would be useful for the cygwin project? setup.exe doesn't suck that much. Just the memory footprint sucks, the UI partly sucks, and update cycles suck. I'd say that judging from the number of complaints we've gotten, the UI more than partly sucks. Personally, I liked the 'cycle thingy' that DJ invented for this project but apparently it is tremendously difficult to understand. Also the manual dependency requirement sucks. Peopple are always getting it wrong. The way dependencies are handled in installation sucks. I could go on but I was trying not to start a diatribe against setup.exe. I investigated what other existing packagers do, and how we can use it. I don't think we need to reinvent any wheels here. The last time this came up someone mentioned an existing installer which already does everything we need it to do. I am just too lazy (and too busy) to try to formulate a google search to try to find it. I've been working more than I want to with rpm lately and I see how much better rpm is at dealing with things that we struggle with. That is no surprise. It's been mentioned for years. I've probably even discouraged the use of rpm. However, even as much as rpm sucks (and it does suck in many ways BIG TIME), it is still better than setup.exe, IMO. I believe that it was always Robert's intention to work towards the use of a true package manager someday. That time is now. I can't take it anymore. cgf
Re: setup.exe sucks
Christopher Faylor wrote: I believe that it was always Robert's intention to work towards the use of a true package manager someday. That time is now. I can't take it anymore. Perhaps it's time to begin work on a native port of rpm.exe -- but to avoid any where exactly IS /var/lib/rpm before cygwin is even installed problems, maybe winrpm.exe should store ALL of its stuff in HKCU somewhere. /usr/lib/rpm/* and all. And the installation database. Once that's done, just like the console version of setup.exe preceded the GUI one, then we could talk about using a scripting language/GUI toolkit to drive the rpm backend... Just a thought. Using a native port of dpkg would work, too. -- Chuck
Re: setup.exe sucks
On Tue, Dec 07, 2004 at 03:48:17PM -0500, Christopher Faylor wrote: On Tue, Dec 07, 2004 at 03:37:36PM -0500, Charles Wilson wrote: Christopher Faylor wrote: I believe that it was always Robert's intention to work towards the use of a true package manager someday. That time is now. I can't take it anymore. Perhaps it's time to begin work on a native port of rpm.exe -- but to avoid any where exactly IS /var/lib/rpm before cygwin is even installed problems, maybe winrpm.exe should store ALL of its stuff in HKCU somewhere. /usr/lib/rpm/* and all. I don't think you need a native version of rpm any more than you need a MS_DOS version of rpm when you're installing linux. You do have to have something early on that bootstraps what you need, like setup.exe does now, but it could always install the cygwin first before it does anything. ... or you could use statically linked rpm. -- +---+ | Marcel Telka e-mail: [EMAIL PROTECTED] | |homepage: http://telka.sk/ | |jabber: [EMAIL PROTECTED] | +---+
Re: setup.exe sucks
On Tue, Dec 07, 2004 at 10:17:55PM +0100, Marcel Telka wrote: On Tue, Dec 07, 2004 at 03:48:17PM -0500, Christopher Faylor wrote: On Tue, Dec 07, 2004 at 03:37:36PM -0500, Charles Wilson wrote: Christopher Faylor wrote: I believe that it was always Robert's intention to work towards the use of a true package manager someday. That time is now. I can't take it anymore. Perhaps it's time to begin work on a native port of rpm.exe -- but to avoid any where exactly IS /var/lib/rpm before cygwin is even installed problems, maybe winrpm.exe should store ALL of its stuff in HKCU somewhere. /usr/lib/rpm/* and all. I don't think you need a native version of rpm any more than you need a MS_DOS version of rpm when you're installing linux. You do have to have something early on that bootstraps what you need, like setup.exe does now, but it could always install the cygwin first before it does anything. ... or you could use statically linked rpm. Sigh. cgf
Re: setup.exe sucks
Christopher Faylor schrieb: On Tue, Dec 07, 2004 at 10:17:55PM +0100, Marcel Telka wrote: On Tue, Dec 07, 2004 at 03:48:17PM -0500, Christopher Faylor wrote: On Tue, Dec 07, 2004 at 03:37:36PM -0500, Charles Wilson wrote: Christopher Faylor wrote: I believe that it was always Robert's intention to work towards the use of a true package manager someday. That time is now. I can't take it anymore. Perhaps it's time to begin work on a native port of rpm.exe -- but to avoid any where exactly IS /var/lib/rpm before cygwin is even installed problems, maybe winrpm.exe should store ALL of its stuff in HKCU somewhere. /usr/lib/rpm/* and all. I don't think you need a native version of rpm any more than you need a MS_DOS version of rpm when you're installing linux. You do have to have something early on that bootstraps what you need, like setup.exe does now, but it could always install the cygwin first before it does anything. ... or you could use statically linked rpm. But rpm doesn't handle Recommends and other UI interactions other UI packagers offer. But better than nothing or our current setup.ini. At least yum can be used then. I already prepared a yum package, but didn't finish proper testing. -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/
Re: setup.exe sucks
On Tue, Dec 07, 2004 at 10:50:36PM +0100, Reini Urban wrote: Christopher Faylor schrieb: On Tue, Dec 07, 2004 at 10:17:55PM +0100, Marcel Telka wrote: On Tue, Dec 07, 2004 at 03:48:17PM -0500, Christopher Faylor wrote: On Tue, Dec 07, 2004 at 03:37:36PM -0500, Charles Wilson wrote: Christopher Faylor wrote: I believe that it was always Robert's intention to work towards the use of a true package manager someday. That time is now. I can't take it anymore. Perhaps it's time to begin work on a native port of rpm.exe -- but to avoid any where exactly IS /var/lib/rpm before cygwin is even installed problems, maybe winrpm.exe should store ALL of its stuff in HKCU somewhere. /usr/lib/rpm/* and all. I don't think you need a native version of rpm any more than you need a MS_DOS version of rpm when you're installing linux. You do have to have something early on that bootstraps what you need, like setup.exe does now, but it could always install the cygwin first before it does anything. ... or you could use statically linked rpm. But rpm doesn't handle Recommends and other UI interactions other UI packagers offer. But better than nothing or our current setup.ini. That's right. RPM does not have Recommends, and that would be nice. It isn't designed to be UI based, though. At least yum can be used then. I already prepared a yum package, but didn't finish proper testing. Yes, once we had yum, we could almost have the unattended install working. Of course, you couldn't use yum to install python or cygwin, as it stands right now. Btw, in case my Sigh wasn't clear, you can't produce statically linked binaries right now with cygwin and I'm not really interested in getting things working that way. You'd still have the same issues with multiple cygwin DLLs that you do now. It would just be harder to detect. A year or so ago someone triumphantly announced that they had produce a way to bundle the cygwin DLL (or any DLL) with an application so that there was no need to have two separate files. Anyone remember that? cgf
Re: setup.exe sucks
Christopher Faylor wrote: That's right. RPM does not have Recommends, and that would be nice. It isn't designed to be UI based, though. Is this a real problem? Wouldn't the eventual solution still have to have a setup.ini-like file, that at least lists all the available packages? You can use that to add 'recommends' functionality on top of RPM in the UI.
Re: setup.exe sucks
On Tue, Dec 07, 2004 at 03:25:11PM -0700, Warren Young wrote: Christopher Faylor wrote: That's right. RPM does not have Recommends, and that would be nice. It isn't designed to be UI based, though. Is this a real problem? Wouldn't the eventual solution still have to have a setup.ini-like file, that at least lists all the available packages? You can use that to add 'recommends' functionality on top of RPM in the UI. Sure, we could do that. We could also add our own variables to the rpm spec files so that they could be queried later. That would keep all of the information in one place. cgf
Re: setup.exe sucks
Christopher Faylor wrote: On Tue, Dec 07, 2004 at 03:37:36PM -0500, Charles Wilson wrote: Perhaps it's time to begin work on a native port of rpm.exe -- but to avoid any where exactly IS /var/lib/rpm before cygwin is even installed problems, maybe winrpm.exe should store ALL of its stuff in HKCU somewhere. /usr/lib/rpm/* and all. I don't think you need a native version of rpm any more than you need a MS_DOS version of rpm when you're installing linux. Point taken. You do have to have something early on that bootstraps what you need, like setup.exe does now, but it could always install the cygwin first before it does anything. Oh, well in that case, maybe a closer look at Dario's unfinished RPM-based distribution. IIRC, it installed a bootstrap cygwin (compiled with a different shared mem keyword or something) and an rpm linked against that... RPM installer (was Re: SETUP WIZARD FOR CYGWIN?XFREE86) http://sources.redhat.com/ml/cygwin/2001-07/msg01429.html Also, the parent thread has some relevant discussion -- as it jumped across different mailing lists. SETUP WIZARD FOR CYGWIN?XFREE86 http://www.cygwin.com/ml/cygwin-xfree/2001-q3/msg00377.html http://www.cygwin.com/ml/cygwin/2001-07/msg01355.html http://www.cygwin.com/ml/cygwin-apps/2001-07/msg00064.html Proposed RPM Installer Design http://www.cygwin.com/ml/cygwin-apps/2001-07/msg00074.html Unfortunately, it seems that the design documenst (and the actual dist ISO) is no longer available: http://www.helixdigital.com/~alcocer/rpm-installer/ gets a 404. The wayback machine helps, for the design document: http://web.archive.org/web/20020203174437/http://www.helixdigital.com/~alcocer/rpm-installer/ http://web.archive.org/web/20020204015116/http://www.helixdigital.com/~alcocer/rpm-installer/rpm-installer_1.html http://web.archive.org/web/20020204020042/http://www.helixdigital.com/~alcocer/rpm-installer/rpm-installer_2.html http://web.archive.org/web/20020204015647/http://www.helixdigital.com/~alcocer/rpm-installer/rpm-installer_3.html http://web.archive.org/web/20020204020143/http://www.helixdigital.com/~alcocer/rpm-installer/rpm-installer_4.html Dario's last message on this subject (24 Jul 2001) includes the following paragraph: Anyway, at some point I'd like to be able to offer it to the Cygwin project. Unfortunately, it's still very immature to be widely released, which is why I had not suggested or mentioned it before. Nevertheless, if any of you are interested in playing around with the installer, I could put a CD-ROM .iso image (~13MB) up on my web site eventually when the work is done (I hope to have a very rough first release by the middle of August. But AFAICT, he never actually put it on the helixdigital site. DarioOh, Dario I understand about the Recommends issue, but somehow I still think that separating UI issues (which IMO Recommeds is) from backend, system issues (like real dependencies), is a good idea. If RPM (or dpkg, whatever -- I'm not religious about this) handles all the backend stuff well, AND we can deal with the bootstrapping issues, then relegating other stuff like Recommendations to the GUI frontend seems okay to me. FWIW, this was interesting (and funny, given the context of the current thread): http://www.cygwin.com/ml/cygwin-apps/2001-11/msg00612.html If we're going to go with a two phase setup, then [Dario's] idea makes more sense than continuing to roll our own. The big argument against his plan was (a) two phase is bad (b) why throw away our perfectly good setup tool. Okay, that's two arguments. ;-) -- Chuck
Re: setup.exe sucks
Christopher Faylor schrieb: On Tue, Dec 07, 2004 at 10:50:36PM +0100, Reini Urban wrote: But rpm doesn't handle Recommends and other UI interactions other UI packagers offer. But better than nothing or our current setup.ini. That's right. RPM does not have Recommends, and that would be nice. It isn't designed to be UI based, though. At least yum can be used then. I already prepared a yum package, but didn't finish proper testing. Yes, once we had yum, we could almost have the unattended install working. Of course, you couldn't use yum to install python or cygwin, as it stands right now. A simple MSI? I'll try that out after the postgresql-8.0 release, in about two weeks or so. ... or you could use statically linked rpm. Btw, in case my Sigh wasn't clear, you can't produce statically linked binaries right now with cygwin and I'm not really interested in getting things working that way. You'd still have the same issues with multiple cygwin DLLs that you do now. It would just be harder to detect. But we could produce a simple installer, which checks the registry for the existing mountpoints to find our already installed cygwin1.dll. If not, install cygwin1.dll, sh.exe, rpm.exe and optionally a bigger graphical packager. With python and some UI it will get very big. Look at the current bittorrent packages, which include the wxpython dll's. Let the user preselect in the simple installer some handy base packages to be installed by rpm from some mirror, and let the rest be done by rpm and friends. At the cmdline or graphically. The needed spec files are almost the same as our current gbs rules + setup.hint Scenario: cygwin.com Install Cygwin now = cygwin.msi or setup.exe = Dialog dependent on the existing setup: * cygwin already installed: check for necessary cygwin, ash and rpm update. select a mirror and download. if the preferred graphical packager is already present and selected last time, start this app and continue with that. if no graphical packager is installed or selected last time, start a console and echo some basic rpm hints. rpm -i mirror/package * or fresh: select a mirror and download cygwin, ash and rpm. ask if you want to continue with a graphical packager (long download...) or cmdline. start this app as above. This way the user can switch packagers as he wants and we only have to enable a radiobutton in the installer, start the rpm process to install this packager and continue with that. even not rpm-based ones, like dpkg or emerge. A year or so ago someone triumphantly announced that they had produce a way to bundle the cygwin DLL (or any DLL) with an application so that there was no need to have two separate files. Anyone remember that? Sounds tricky: Probably with attaching the dll as ressource into the exe, MapViewOfFile this ressource on startup, work around LoadLibrary, find all the symbols and fill the relocation table with the found syms. Bootstrap then. Some kind of hand-made lazy loading. If the OS allows writing into that area. Or fill some prefabricated stubs (some binutils magic) with the syms in the ressource. -- Reini
