From: Brian Dunford-S. <bh...@ea...> - 2004-05-09 16:37:56
Attachments:
installing_cooperative_linux.htm
|
The following section of this message contains a file attachment prepared for transmission using the Internet MIME message format. If you are using Pegasus Mail, or any other MIME-compliant system, you should be able to save it or view it from within your mailer. If you cannot, please ask your system administrator for assistance. ---- File information ----------- File: installing_cooperative_linux.htm Date: 5 May 2004, 23:04 Size: 21109 bytes. Type: HTML-text |
From: Brian Dunford-S. <bh...@ea...> - 2004-05-09 16:37:56
|
Attached is an installer script for NullSoft (install_colinux.nsi) that creates an installer: Install_Colinux.exe. Excerpts from the documentation page that is installed is included below to explain what the distribution is for. The installer script has been modified to remove/install the Cooperative Linux driver (as an option that is on by default). Once I have done just a little more testing (and maybe updated the documentation more) I will be trying to find a home on the web for this distribution so that others may download and use it. I am open to having the ideas in this just folded into other distribution (instead of creating just another distribution). Brian H. Dunford-Shore bh...@ea... =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3DExcerpt from documentation=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Introduction This distribution of Cooperative Linux is meant to provide a complete and relatively easy-to-use setup of Cooperative Linux. It is complete in the s= ense that it will install the Cooperative Linux programs and Linux kernel, let = you choose to install a Linux file system file and swap device, it will write configuration files for each file system installed, it will (optionally) i= nstall Cooperative Linux as a Service, and it will provide menu items for startin= g, and configuring Cooperative Linux. The instructions below all assume that you have full administrative access= to your computer. It is meant to be installed on a Windows 2000 or Windows XP computer with a file system that is using NTFS (the default file system type for Window = 2000 or XP). See the following section on Disk Space Usage for behavior on non NTFS file systems. Disk Space Usage It may be installed on a file system that uses FAT or FAT32, but it will t= hen use the real size of the files (1GB for the Debian distribution, 6GB for t= he Fedora Core 1 distribution and 256MB or 2GB for the swap device). If it is= installed on an NTFS file system, then it will only use the amount of spac= e that Linux is currently really using=94not the amount of space allocated for th= e Linux file system. The following table shows the installed sizes for the g= ive Linux 'devices': File system Approximate Real Space Allocated device file Space Used =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Debian (root_fs) 66MB 1GB Fedora Core 1 (fc1_6gb_root) 399MB 6GB 256 MB swap device 128KB 256MB 2GB swap device 128KB 2GB So on an NTFS file system, the second column shows the space really used while on FAT or FAT32 (if a file that large could be held by that file sys= tem) the third column shows the amount of space that would be used. NOTE: if you install more files and use more space in Cooperative Linux (or use swa= p space for the swap devices) then the amount of Windows file system space used will grow and can grow to the amount of space given in the third column. Cooperative Linux Menus The installation package has installed menus (select the Start menu in the= lower left hand corner, followed by Programs and Cooperative Linux). There are menu items for: * Checking or changing your Cooperative Linux configuration * Starting the Cooperative Linux Daemon * Starting the Cooperative Linux Console * Starting the Cooperative Linux Console (with an NT console) * Starting the Cooperative Linux Service (see the Cooperative Linux Service configuration section below for some additional information before attempting this). |
From: Robert C. <rw...@al...> - 2004-05-09 16:56:46
|
Hello Brian, On Sunday, May 9, 2004, at 11:37 US/Central, Brian Dunford-Shore wrote: > Attached is an installer script for NullSoft > (install_colinux.nsi) that creates an installer: > Install_Colinux.exe. Excerpts from the documentation page > that is installed is included below to explain what the > distribution is for. Thanks for creating this. I'm only vaguely familiar with NullSoft, but it looks as though this .nsi script requires Cygwin (binaries and .dlls) to build either build the installer and/or to actually install coLinux. Am I reading the .nsi file correctly? If I am, what is Cygwin used for and is there any way to eliminate the need for Cygwin? Regards, - Robert |
From: Brian Dunford-S. <bh...@ea...> - 2004-05-09 20:00:20
|
> Thanks for creating this. I'm only vaguely familiar with NullSoft, but > it looks as though this .nsi script requires Cygwin (binaries and > .dlls) to build either build the installer and/or to actually install > coLinux. Am I reading the .nsi file correctly? If I am, what is > Cygwin used for and is there any way to eliminate the need for Cygwin? It uses some of the Cygwin binaries during the install. It copies the Cygwin binaries into the TEMP directory, runs them from there, and then removes them by the end of the install. They are never installed on the system. This is no different then Microsoft or other installers that use a VB runtime or other needed installer executable during the install--it is just the opensource equivalent. Note that Cooperative Linux still has no dependency on Cygwin and that the system being installed to may or may not have Cygwin before and after the install. It is using the Cygwin tar.exe to unpack the root filesystem and swap device device files in sparse form. This is the best way that I currently know of to deliver these in sparse form. Check the documentation I posted earlier for the space savings this gives to the users. I am also using the Cygwin perl.exe to produce configuration files and command files with the appropriate settings that the user has selected during the install. This could be done in other ways--I am just most comfortable in perl (other people may prefer python or something else). I have added to the end of this message the mkcfg.pl perl script that I currently use for this. Brian Dunford-Shore ==============mkcfg.pl=============================== #!/usr/bin/perl # DON'T USE STRICT during an install! #use strict; # Installation directory is first argument my($inst_dir) = shift; # Output configuration file is second argument my($output) = shift; # Filesystem file name is third argument my($root_fs_file) = shift; # Copy config file and update paths and root filesystem name open(CONFIGTMP,"default.colinux.xml") || die "Unable to open configuration template\r\n"; open(CONFIG,">$output"); while(<CONFIGTMP>) { s/c:\\colinux/$inst_dir/gi; s/root_fs/$root_fs_file/g; chomp; print CONFIG "$_\r\n"; } close(CONFIG); close(CONFIGTMP); open(CFGCMD,">cfg_colinux.cmd"); print CFGCMD "\@echo off\r\n"; print CFGCMD "start \"\%WINDIR\%\\system32\\notepad.exe\" \"$inst_dir\\$output\"\r\n"; close(CFGCMD); # Write a batch file to run the colinux daemon with this configuration. open(SRVCMD,">colinux.cmd"); print SRVCMD "\@echo off\r\n"; print SRVCMD "\"$inst_dir\\colinux-daemon.exe\" --remove- driver\r\n"; print SRVCMD "\"$inst_dir\\colinux-daemon.exe\" -c \"$inst_dir\\$output\"\r\n"; close(SRVCMD); # Write a batch file to install the service. # This is ran by the setup program if the user chooses that option. open(SRVCMD,">install_service.cmd"); print SRVCMD "\@echo off\r\n"; print SRVCMD "\"$inst_dir\\colinux-daemon.exe\" --remove- driver\r\n"; print SRVCMD "\"$inst_dir\\colinux-daemon.exe\" --install- driver\r\n"; print SRVCMD "\"$inst_dir\\colinux-daemon.exe\" -c \"$inst_dir\\$output\" --install-service\r\n"; close(SRVCMD); # Write a batch file to uninstall the service. # This may be ran by the user to uninstall the service. open(SRVCMD,">uninstall_service.cmd"); print SRVCMD "\@echo off\r\n"; print SRVCMD "\"$inst_dir\\colinux-daemon.exe\" --remove- service\r\n"; print SRVCMD "\"$inst_dir\\colinux-daemon.exe\" --remove- driver\r\n"; close(SRVCMD); exit; |
From: peter g. <plu...@p1...> - 2004-05-09 20:26:36
|
it may be a good idea to try and remove this requirement from the instaler if possible cygwin uses shared memory and different versions of the dll do not play nice might be an idea to look at the mingw tools instead -----Original Message----- From: col...@li... [mailto:col...@li...]On Behalf Of Brian Dunford-Shore Sent: 09 May 2004 21:00 To: col...@li... Subject: Re: [coLinux-devel] Installer for CoLinux > Thanks for creating this. I'm only vaguely familiar with NullSoft, but > it looks as though this .nsi script requires Cygwin (binaries and > .dlls) to build either build the installer and/or to actually install > coLinux. Am I reading the .nsi file correctly? If I am, what is > Cygwin used for and is there any way to eliminate the need for Cygwin? It uses some of the Cygwin binaries during the install. It copies the Cygwin binaries into the TEMP directory, runs them from there, and then removes them by the end of the install. They are never installed on the system. This is no different then Microsoft or other installers that use a VB runtime or other needed installer executable during the install--it is just the opensource equivalent. Note that Cooperative Linux still has no dependency on Cygwin and that the system being installed to may or may not have Cygwin before and after the install. It is using the Cygwin tar.exe to unpack the root filesystem and swap device device files in sparse form. This is the best way that I currently know of to deliver these in sparse form. Check the documentation I posted earlier for the space savings this gives to the users. I am also using the Cygwin perl.exe to produce configuration files and command files with the appropriate settings that the user has selected during the install. This could be done in other ways--I am just most comfortable in perl (other people may prefer python or something else). I have added to the end of this message the mkcfg.pl perl script that I currently use for this. Brian Dunford-Shore ==============mkcfg.pl=============================== #!/usr/bin/perl # DON'T USE STRICT during an install! #use strict; # Installation directory is first argument my($inst_dir) = shift; # Output configuration file is second argument my($output) = shift; # Filesystem file name is third argument my($root_fs_file) = shift; # Copy config file and update paths and root filesystem name open(CONFIGTMP,"default.colinux.xml") || die "Unable to open configuration template\r\n"; open(CONFIG,">$output"); while(<CONFIGTMP>) { s/c:\\colinux/$inst_dir/gi; s/root_fs/$root_fs_file/g; chomp; print CONFIG "$_\r\n"; } close(CONFIG); close(CONFIGTMP); open(CFGCMD,">cfg_colinux.cmd"); print CFGCMD "\@echo off\r\n"; print CFGCMD "start \"\%WINDIR\%\\system32\\notepad.exe\" \"$inst_dir\\$output\"\r\n"; close(CFGCMD); # Write a batch file to run the colinux daemon with this configuration. open(SRVCMD,">colinux.cmd"); print SRVCMD "\@echo off\r\n"; print SRVCMD "\"$inst_dir\\colinux-daemon.exe\" --remove- driver\r\n"; print SRVCMD "\"$inst_dir\\colinux-daemon.exe\" -c \"$inst_dir\\$output\"\r\n"; close(SRVCMD); # Write a batch file to install the service. # This is ran by the setup program if the user chooses that option. open(SRVCMD,">install_service.cmd"); print SRVCMD "\@echo off\r\n"; print SRVCMD "\"$inst_dir\\colinux-daemon.exe\" --remove- driver\r\n"; print SRVCMD "\"$inst_dir\\colinux-daemon.exe\" --install- driver\r\n"; print SRVCMD "\"$inst_dir\\colinux-daemon.exe\" -c \"$inst_dir\\$output\" --install-service\r\n"; close(SRVCMD); # Write a batch file to uninstall the service. # This may be ran by the user to uninstall the service. open(SRVCMD,">uninstall_service.cmd"); print SRVCMD "\@echo off\r\n"; print SRVCMD "\"$inst_dir\\colinux-daemon.exe\" --remove- service\r\n"; print SRVCMD "\"$inst_dir\\colinux-daemon.exe\" --remove- driver\r\n"; close(SRVCMD); exit; --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.672 / Virus Database: 434 - Release Date: 28/04/2004 |
From: Dan A. <da...@co...> - 2004-05-10 06:50:29
|
On Sun, May 09, 2004 at 03:00:18PM -0500, Brian Dunford-Shore wrote: > > Thanks for creating this. I'm only vaguely familiar with > NullSoft, but > > it looks as though this .nsi script requires Cygwin > (binaries and > > .dlls) to build either build the installer and/or to > actually install > > coLinux. Am I reading the .nsi file correctly? If I am, > what is > > Cygwin used for and is there any way to eliminate the need > for Cygwin? > > It uses some of the Cygwin binaries during the install. It > copies the Cygwin binaries into the TEMP directory, runs them > from there, and then removes them by the end of the install. > They are never installed on the system. This is no different > then Microsoft or other installers that use a VB runtime > or other needed installer executable during the install--it is > just the opensource equivalent. Note that Cooperative Linux > still has no dependency on Cygwin and that the system being > installed to may or may not have Cygwin before and after the > install. How about using the mingw32 executables available from http://www.mingw.org/ ? I really like what you have done with the installer, but it must not depend on Cygwin for us to accept it. I'm looking forward to incoprate the changes into the official coLinux installer. -- Dan Aloni da...@co... |
From: Bill C. R. <do...@fr...> - 2004-05-10 13:34:54
|
> Note that Cooperative Linux still has no dependency on Cygwin and that = the system being installed to may or may not have Cygwin before and = after the install. Not quite true. There is a restriction with cygwin that only one = cygwin.dll may be loaded in memory at any given time. If the dll = shipped with coLinux is different than the one for the cygwin system = installed, either coLinux will fail to work, or some of the cygwin = utilities. Since it is most likely the incompatabilities would be with = library calls coLinux does not use, it is most likely users will only = see problems if they start coLinux first and then try running cygwin = utilities... The best way around this problem is if coLinux was available as a cygwin = package for those who already have cygwin. Those who already have = cygwin could use that package. Those who don't have coLinux would use a = windows installer which installs the cygwin.dll. BTW. When distributing a copy of cygwin.dll it is best to include = information about what build was used, so people can obtain the correct = source later, should it be required. Bill |
From: <ch...@to...> - 2004-05-10 16:31:52
|
The current snapshots are being built with mingw. Yes the last "release" used cygwin.dll but the next release will not. So cygwin is only necessar= y for those using it for X or other things. For utilities like tar there is an mingw version. The use of perl in the installer may be slightly more difficult. AFAIK perl is has not been buil= t under mingw. active perl is free but must be downloaded by end user not redistributed. Here are some other perl ports for win not shure which may work. http://www.cpan.org/ports/#win32 chris >> Note that Cooperative Linux still has no dependency on Cygwin and that >> the system being installed to may or may not have Cygwin before and >> after the install. > > > Not quite true. There is a restriction with cygwin that only one > cygwin.dll may be loaded in memory at any given time. If the dll shipp= ed > with coLinux is different than the one for the cygwin system installed, > either coLinux will fail to work, or some of the cygwin utilities. Sin= ce > it is most likely the incompatabilities would be with library calls > coLinux does not use, it is most likely users will only see problems if > they start coLinux first and then try running cygwin utilities... > > The best way around this problem is if coLinux was available as a cygwi= n > package for those who already have cygwin. Those who already have cygw= in > could use that package. Those who don't have coLinux would use a windo= ws > installer which installs the cygwin.dll. > > BTW. When distributing a copy of cygwin.dll it is best to include > information about what build was used, so people can obtain the correct > source later, should it be required. > > Bill > |
From: Bill C. R. <do...@fr...> - 2004-05-10 16:41:43
|
Ok. It would be interesting to know how usage of coLinux breaks down in proportion to those using it with cygwin, v.s. those using it without cygwin. Until someone figures out a way to run X11 natively under coLinux I expect the larger percentage will be using coLinux with cygwin. Personally, I would much prefer to have coLinux using cygwin POSIX paths and libraries than using MingW, as most of the time I invoke coLinux as if it was an X11 application. Even better is if the user installing could decide which was desired. Bill ----- Original Message ----- From: <ch...@to...> To: "Bill C. Riemers" <do...@fr...> Cc: <bh...@ea...>; <col...@li...> Sent: Monday, May 10, 2004 12:31 PM Subject: Re: [coLinux-devel] Installer for CoLinux > The current snapshots are being built with mingw. Yes the last "release" > used cygwin.dll but the next release will not. So cygwin is only necessary > for those using it for X or other things. > > For utilities like tar there is an mingw version. The use of perl in the > installer may be slightly more difficult. AFAIK perl is has not been built > under mingw. active perl is free but must be downloaded by end user not > redistributed. Here are some other perl ports for win not shure which may > work. > http://www.cpan.org/ports/#win32 > > chris > > > >> Note that Cooperative Linux still has no dependency on Cygwin and that > >> the system being installed to may or may not have Cygwin before and > >> after the install. > > > > > > Not quite true. There is a restriction with cygwin that only one > > cygwin.dll may be loaded in memory at any given time. If the dll shipped > > with coLinux is different than the one for the cygwin system installed, > > either coLinux will fail to work, or some of the cygwin utilities. Since > > it is most likely the incompatabilities would be with library calls > > coLinux does not use, it is most likely users will only see problems if > > they start coLinux first and then try running cygwin utilities... > > > > The best way around this problem is if coLinux was available as a cygwin > > package for those who already have cygwin. Those who already have cygwin > > could use that package. Those who don't have coLinux would use a windows > > installer which installs the cygwin.dll. > > > > BTW. When distributing a copy of cygwin.dll it is best to include > > information about what build was used, so people can obtain the correct > > source later, should it be required. > > > > Bill > > > |
From: Robert C. <rw...@al...> - 2004-05-10 17:44:30
|
On Monday, May 10, 2004, at 11:41 US/Central, Bill C. Riemers wrote: > Ok. It would be interesting to know how usage of coLinux breaks down > in > proportion to those using it with cygwin, v.s. those using it without > cygwin. While that is interesting to know, let's first make the installer work for everyone, then we can make it work better. Right now, I do not even know what I need in order to test the installer. Ideally, I would like to have a self-extracting archive that contains everything I need ready for testing. That includes the colinux binaries, configuration files, Readme, the .nsi file, any tools, etc. - the whole package. If we had that, then steps on a Windows machine would be: - extract package - open .nsi file - compile - adjust, wash, rinse, repeat For now all I have is an .nsi file, a bunch of coLinux binaries that I built myself, and too many other things going on to RTFM and figure out how to put the pieces together. Regards, - Robert |
From: tei <42...@in...> - 2004-05-10 18:57:23
|
ch...@to... wrote: > The current snapshots are being built with mingw. Yes the last "release" > used cygwin.dll but the next release will not. So cygwin is only necessary > for those using it for X or other things. > > For utilities like tar there is an mingw version. The use of perl in the > installer may be slightly more difficult. AFAIK perl is has not been built > under mingw. active perl is free but must be downloaded by end user not > redistributed. Here are some other perl ports for win not shure which may > work. > http://www.cpan.org/ports/#win32 > > chris > a installer that use cygwin1.dll will be a problem for these people running daemons that already use cygwin1.dll different version. as I understand all other emails. I think can be a option, maybe a solution workaround, to change temporally the 'path' so older/alternate versions of cygwin1.dll where invisible while coLinux install. Here is some assembler pseudocode: . . push path set path to a friendly one unzip cygwin1.dll install with perl, tar and whatever remove cygwin1.dll,etc.. pop path . . . my 0.02 € |
From: David K. <da...@gi...> - 2004-05-10 23:20:55
|
hi chris, ch...@to... wrote: > > For utilities like tar there is an mingw version. The use of perl in > the installer may be slightly more difficult. AFAIK perl is has not > been built under mingw. active perl is free but must be downloaded by > end user not redistributed. ActiveState's perl may (or may not) be redistributable -- i'm not sure though, as you point out, anyone can download it, but if we have perl script that we'd like to distribute, i have their Perl Development Kit (specifically, the PerlApp component) which allows you to "compile" your perl scripts and their dependent modules, resources, like icons, etc, and even data files and core perl itself, into a standalone Win32 .exe-cutable. the resulting binaries are most *definitely* redistributable (that's the whole point), and convenient to distribute as well, since they require no prior perl installattion on the target system. i'd be happy to bundle any perl parts we need up into these little PerlApp's for the coLinux installer effort, if that would be helpful! -dave |
From: Robert C. <rw...@al...> - 2004-05-11 04:32:35
|
On Monday, May 10, 2004, at 18:20 US/Central, David Kaufman wrote: > ActiveState's perl may (or may not) be redistributable I had a short but informative e-mail exchange with ActiveState about a year ago. Although you can freely download it, their perl is definitely not redistributable. Regards, - Robert |
From: Martin K. <ka...@po...> - 2004-05-12 21:46:38
|
To replace this perl script with onboard cmd-file i could imagine something like this: generate.cmd <target_dir> <root_fs> <config_file> ------------------------------------------------- echo off ... echo echo off >%1\install_service.cmd echo "%1\colinux-daemon.exe" --remove-driver >>%1\install_service.cmd echo "%1\colinux-daemon.exe" --install-driver >>%1\install_service.cmd echo "%1\colinux-daemon.exe" -c "%1\%2\" --install-driver >>%1\install_service.cmd ... -------------------------------------------------- or have some cmds with usage like generate_install_service.cmd {target_dir} {root_fs} {config_file} > install_service.cmd for that nice config generation i have no nice suggestion. but an config program with ability to handle nics could be nice and useful, so it need not to be in setup itself. i started to write one, but because of it's written in Delphi, i can't imagine to integrate it to colinux (even though it is to compile with personal version of delphi). Perl is nice, but if you could get it run without cygwin and perl installation, it would be nice. On the other hand i wonder if nsis supports no scripting like InnoSetup. Regards, Martin Brian Dunford-Shore wrote: >> Thanks for creating this. I'm only vaguely familiar with NullSoft, but >> it looks as though this .nsi script requires Cygwin (binaries and >> .dlls) to build either build the installer and/or to actually install >> coLinux. Am I reading the .nsi file correctly? If I am, what is >> Cygwin used for and is there any way to eliminate the need for Cygwin? > > It uses some of the Cygwin binaries during the install. It copies the > Cygwin binaries into the TEMP directory, runs them from there, and then > removes them by the end of the install. They are never installed on the > system. This is no different then Microsoft or other installers that > use a VB runtime > or other needed installer executable during the install--it is just the > opensource equivalent. Note that Cooperative Linux still has no > dependency on Cygwin and that the system being installed to may or may > not have Cygwin before and after the install. > > It is using the Cygwin tar.exe to unpack the root filesystem and swap > device device files in sparse form. This is the best way that I > currently know of to deliver these in sparse form. Check the > documentation I posted earlier for the space savings this gives to the > users. > > I am also using the Cygwin perl.exe to produce configuration files and > command files with the appropriate settings that the user has selected > during the install. This could be done in other ways--I am just most > comfortable in perl (other people > may prefer python or something else). I have added to the end of this > message the mkcfg.pl perl script that I currently use for this. > > Brian Dunford-Shore > > ==============mkcfg.pl=============================== > > > #!/usr/bin/perl > > # DON'T USE STRICT during an install! > #use strict; > > # Installation directory is first argument > my($inst_dir) = shift; > # Output configuration file is second argument > my($output) = shift; > # Filesystem file name is third argument > my($root_fs_file) = shift; > > # Copy config file and update paths and root filesystem name > open(CONFIGTMP,"default.colinux.xml") || die "Unable to open > configuration template\r\n"; > open(CONFIG,">$output"); > while(<CONFIGTMP>) { > s/c:\\colinux/$inst_dir/gi; > s/root_fs/$root_fs_file/g; > chomp; > print CONFIG "$_\r\n"; > } > close(CONFIG); > close(CONFIGTMP); > > open(CFGCMD,">cfg_colinux.cmd"); > print CFGCMD "\@echo off\r\n"; > print CFGCMD "start \"\%WINDIR\%\\system32\\notepad.exe\" > \"$inst_dir\\$output\"\r\n"; > close(CFGCMD); > > # Write a batch file to run the colinux daemon with this configuration. > open(SRVCMD,">colinux.cmd"); > print SRVCMD "\@echo off\r\n"; > print SRVCMD "\"$inst_dir\\colinux-daemon.exe\" --remove- driver\r\n"; > print SRVCMD "\"$inst_dir\\colinux-daemon.exe\" -c > \"$inst_dir\\$output\"\r\n"; > close(SRVCMD); > > # Write a batch file to install the service. > # This is ran by the setup program if the user chooses that option. > open(SRVCMD,">install_service.cmd"); > print SRVCMD "\@echo off\r\n"; > print SRVCMD "\"$inst_dir\\colinux-daemon.exe\" --remove- driver\r\n"; > print SRVCMD "\"$inst_dir\\colinux-daemon.exe\" --install- driver\r\n"; > print SRVCMD "\"$inst_dir\\colinux-daemon.exe\" -c > \"$inst_dir\\$output\" --install-service\r\n"; > close(SRVCMD); > > # Write a batch file to uninstall the service. > # This may be ran by the user to uninstall the service. > open(SRVCMD,">uninstall_service.cmd"); > print SRVCMD "\@echo off\r\n"; > print SRVCMD "\"$inst_dir\\colinux-daemon.exe\" --remove- service\r\n"; > print SRVCMD "\"$inst_dir\\colinux-daemon.exe\" --remove- driver\r\n"; > close(SRVCMD); > > exit; |
From: boots <jay...@ya...> - 2004-05-12 22:58:46
|
Hi all, I have been working on a dos batch file based installer/management tool. Amoung other things, it has initial support for handling dependencies for autostarting services at boot time. It does this by examining the xml configuration and deciding what to do from there. It can handle several setup issues or at least tries to provide tools that might help. Useful for those who like to live at a command line or script items. Recently, I added initial support for automated d/l and install of snapshots. This portion currently requires cygwin, but I am looking at ways to get around that need. It is still very young (1.2.7) but usable. More info and the code itself is available at: http://colinux.servebeer.com/clm/ Have Fun! xo boots __________________________________ Do you Yahoo!? Yahoo! Movies - Buy advance tickets for 'Shrek 2' http://movies.yahoo.com/showtimes/movie?mid=1808405861 |
From: George P B. <geo...@gm...> - 2006-05-26 21:48:34
|
On 5/10/04, ch...@to... <ch...@to...> wrote: > The current snapshots are being built with mingw. Yes the last "release" > used cygwin.dll but the next release will not. So cygwin is only necessary > for those using it for X or other things. Depending on what you call an "release" and a "snapshot" coLinux has had mingw compiled release for SEVERAL releases now (since like 0.6.2 at the very least), and we are about to release 0.6.4 > For utilities like tar there is an mingw version. The use of perl in the > installer may be slightly more difficult. AFAIK perl is has not been built > under mingw. active perl is free but must be downloaded by end user not > redistributed. Here are some other perl ports for win not shure which may > work. > http://www.cpan.org/ports/#win32 > > chris > > > >> Note that Cooperative Linux still has no dependency on Cygwin and that > >> the system being installed to may or may not have Cygwin before and > >> after the install. > > > > > > Not quite true. There is a restriction with cygwin that only one > > cygwin.dll may be loaded in memory at any given time. If the dll shipped > > with coLinux is different than the one for the cygwin system installed, > > either coLinux will fail to work, or some of the cygwin utilities. Since > > it is most likely the incompatabilities would be with library calls > > coLinux does not use, it is most likely users will only see problems if > > they start coLinux first and then try running cygwin utilities... > > > > The best way around this problem is if coLinux was available as a cygwin > > package for those who already have cygwin. Those who already have cygwin > > could use that package. Those who don't have coLinux would use a windows > > installer which installs the cygwin.dll. > > > > BTW. When distributing a copy of cygwin.dll it is best to include > > information about what build was used, so people can obtain the correct > > source later, should it be required. Also, I don't know where but I'm certain I saw an post or article, or comment or some such which throughly DEBUNKED this idea that cygwin.dll had to be the same version for all cygwin based apps. -- George |
From: Juergen H. <jue...@gm...> - 2006-05-26 22:26:43
|
This is one of three mails that got delivered today after two years. This is a little more than the usual SF delay;-) Unfortunately my mailer butches the header so I can't see, where this went wrong. > -------- Original-Nachricht -------- > Datum: Fri, 26 May 2006 16:48:28 -0500 > Von: George P Boutwell <geo...@gm...> > An: ch...@to... <ch...@to...> > Betreff: Re: [coLinux-devel] Installer for CoLinux > > On 5/10/04, ch...@to... <ch...@to...> wrote: > > The current snapshots are being built with mingw. Yes the last "release" > > used cygwin.dll but the next release will not. So cygwin is only > necessary > > for those using it for X or other things. > > Depending on what you call an "release" and a "snapshot" coLinux has > had mingw compiled release for SEVERAL releases now (since like 0.6.2 > at the very least), and we are about to release 0.6.4 > The mail is two years old, so this doesn't apply any longer. > > For utilities like tar there is an mingw version. The use of perl in the > > installer may be slightly more difficult. AFAIK perl is has not been > built > > under mingw. active perl is free but must be downloaded by end user not > > redistributed. Here are some other perl ports for win not shure which > may > > work. > > http://www.cpan.org/ports/#win32 > > > > chris > > > >> >> Note that Cooperative Linux still has no dependency on Cygwin and > that > > >> the system being installed to may or may not have Cygwin before and > > >> after the install. > > > > > >> > Not quite true. There is a restriction with cygwin that only one > > > cygwin.dll may be loaded in memory at any given time. If the dll > shipped > > > with coLinux is different than the one for the cygwin system > installed, > > > either coLinux will fail to work, or some of the cygwin utilities. > Since > > > it is most likely the incompatabilities would be with library calls > > > coLinux does not use, it is most likely users will only see problems > if > > > they start coLinux first and then try running cygwin utilities... > > > > > > The best way around this problem is if coLinux was available as a > cygwin > > > package for those who already have cygwin. Those who already have > cygwin > > > could use that package. Those who don't have coLinux would use a > windows > > > installer which installs the cygwin.dll. > > > > > > BTW. When distributing a copy of cygwin.dll it is best to include > > > information about what build was used, so people can obtain the > correct > > > source later, should it be required. > > Also, I don't know where but I'm certain I saw an post or article, or > comment or some such which throughly DEBUNKED this idea that > cygwin.dll had to be the same version for all cygwin based apps. > You can have different cygwin.dll. The problem is, that you can only have one cygwin.dll loaded at a time. So if you have an application A which comes with a cygwin.dll that is not compatible with the version which is used by application B and you start application A, a start of application B will fail. This is a big problem. So if you have cygwin running for example or use the sshd daemon from cygwin and you want to run an application that uses an older version of the cygwin.dll this will not work. So using cygwin binaries in an installer is not a good idea. Fortunately it is not necessary to use any cygwin binaries to install coLinux. Juergen > -- > George > > _______________________________________________ > coLinux-devel mailing list > coL...@li... > https://lists.sourceforge.net/lists/listinfo/colinux-devel -- Bis zu 70% Ihrer Onlinekosten sparen: GMX SmartSurfer! Kostenlos downloaden: http://www.gmx.net/de/go/smartsurfer |
From: Bjorn S. <sw...@in...> - 2004-05-10 02:00:44
|
So, where do we get the rest of the files to build the install exe ? > -----Original Message----- > From: col...@li... > [mailto:col...@li...] On Behalf > Of Brian Dunford-Shore > Sent: Sunday, May 09, 2004 11:38 AM > To: col...@li... > Subject: [coLinux-devel] Installer for CoLinux > > > > Attached is an installer script for NullSoft > (install_colinux.nsi) that creates an installer: > Install_Colinux.exe. Excerpts from the documentation page > that is installed is included below to explain what the > distribution is for. > > The installer script has been modified to remove/install the > Cooperative Linux driver (as an option that is on by default). > > Once I have done just a little more testing (and maybe updated > the documentation more) I will be trying to find a home on the > web for this distribution so that others may download and use > it. > > I am open to having the ideas in this just folded into other > distribution (instead of creating just another distribution). > > Brian H. Dunford-Shore > bh...@ea... > > > =============Excerpt from documentation===================== > > Introduction > > This distribution of Cooperative Linux is meant to provide a > complete and > relatively easy-to-use setup of Cooperative Linux. It is > complete in the sense > that it will install the Cooperative Linux programs and Linux > kernel, let you > choose to install a Linux file system file and swap device, > it will write > configuration files for each file system installed, it will > (optionally) install > Cooperative Linux as a Service, and it will provide menu > items for starting, > and configuring Cooperative Linux. > > The instructions below all assume that you have full > administrative access to > your computer. > > It is meant to be installed on a Windows 2000 or Windows XP > computer with > a file system that is using NTFS (the default file system > type for Window 2000 > or XP). See the following section on Disk Space Usage for > behavior on non > NTFS file systems. > > Disk Space Usage > > It may be installed on a file system that uses FAT or FAT32, > but it will then > use the real size of the files (1GB for the Debian > distribution, 6GB for the > Fedora Core 1 distribution and 256MB or 2GB for the swap > device). If it is > installed on an NTFS file system, then it will only use the > amount of space that > Linux is currently really using"not the amount of space > allocated for the > Linux file system. The following table shows the installed > sizes for the give > Linux 'devices': > File system Approximate Real Space Allocated > device file Space Used > ========== ================ ============= > Debian (root_fs) 66MB 1GB > > Fedora Core 1 > (fc1_6gb_root) 399MB 6GB > > 256 MB > swap device 128KB 256MB > > 2GB > swap device 128KB 2GB > > So on an NTFS file system, the second column shows the space > really used > while on FAT or FAT32 (if a file that large could be held by > that file system) > the third column shows the amount of space that would be > used. NOTE: if > you install more files and use more space in Cooperative > Linux (or use swap > space for the swap devices) then the amount of Windows file > system space > used will grow and can grow to the amount of space given in the third > column. > > Cooperative Linux Menus > The installation package has installed menus (select the > Start menu in the > lower left hand corner, followed by Programs and Cooperative Linux). > There are menu items for: > * Checking or changing your Cooperative Linux configuration > * Starting the Cooperative Linux Daemon > * Starting the Cooperative Linux Console > * Starting the Cooperative Linux Console (with an NT console) > * Starting the Cooperative Linux Service (see the Cooperative Linux > Service configuration section below for some additional > information > before attempting this). > > > > ------------------------------------------------------- > This SF.Net email is sponsored by Sleepycat Software > Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to > deliver higher performing products faster, at low TCO. > http://www.sleepycat.com/telcomwpreg.php?From=dnemail3 > _______________________________________________ > coLinux-devel mailing list > coL...@li... > https://lists.sourceforge.net/lists/listinfo/colinux-devel > |
From: David K. <da...@gi...> - 2004-05-10 23:10:01
|
Bill C. Riemers <do...@fr...> wrote: > Ok. It would be interesting to know how usage of coLinux breaks down > in proportion to those using it with cygwin, v.s. those using it > without cygwin. Until someone figures out a way to run X11 natively > under coLinux I expect the larger percentage will be using coLinux > with cygwin. perhaps. but i don't (and don't plan to) run X11 natively. my goals for coLinux involve running it as a "headless" service, local webserver, dns server, firewall, etc. --you know, all those things a perl/mod_perl web developer like me needs to be able to develop, test and debug fully functional websites and CGI applications on a laptop, on a train :-) me don't need/want no X11 :-) > Personally, I would much prefer to have coLinux using cygwin POSIX > paths and libraries than using MingW, as most of the time I invoke > coLinux as if it was an X11 application. Even better is if the user > installing could decide which was desired. ok, that's fine. i can see the value in your use case. but please don't assume that your objectives are those of "the majority". i'd like to configure my coLinux just as close as possible to a production webserver in a datacenter, since this is the target environment of the code i develop. this means not having and not needing cygwin or X11 in any way shape or form. so i hope that coLinux will continue to support my "minimalist" needs! -dave |
From: <ch...@to...> - 2004-05-11 11:17:08
|
I agree with Dave here. CoLinux is a general purpose tool. The things tha= t are merged into it should not define how it is used but should contribute to it's versitility kinda like the Linux kernel itself. It should be up t= o the end user or redistributers to bundle it with other things that they feel is appropriate. Probably the best way to make it compatable with cygwin is not to have it depend on cygwin. chris > Bill C. Riemers <do...@fr...> wrote: >> Ok. It would be interesting to know how usage of coLinux breaks down >> in proportion to those using it with cygwin, v.s. those using it >> without cygwin. Until someone figures out a way to run X11 natively >> under coLinux I expect the larger percentage will be using coLinux >> with cygwin. > > perhaps. but i don't (and don't plan to) run X11 natively. my goals f= or > coLinux involve running it as a "headless" service, local webserver, dn= s > server, firewall, etc. --you know, all those things a perl/mod_perl web > developer like me needs to be able to develop, test and debug fully > functional websites and CGI applications on a laptop, on a train :-) m= e > don't need/want no X11 :-) > >> Personally, I would much prefer to have coLinux using cygwin POSIX >> paths and libraries than using MingW, as most of the time I invoke >> coLinux as if it was an X11 application. Even better is if the user >> installing could decide which was desired. > > ok, that's fine. i can see the value in your use case. but please don= 't > assume that your objectives are those of "the majority". i'd like to > configure my coLinux just as close as possible to a production webserve= r > in > a datacenter, since this is the target environment of the code i develo= p. > this means not having and not needing cygwin or X11 in any way shape or > form. so i hope that coLinux will continue to support my "minimalist" > needs! > > -dave > > > > ------------------------------------------------------- > This SF.Net email is sponsored by Sleepycat Software > Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to > deliver higher performing products faster, at low TCO. > http://www.sleepycat.com/telcomwpreg.php?From=3Dosdnemail3 > _______________________________________________ > coLinux-devel mailing list > coL...@li... > https://lists.sourceforge.net/lists/listinfo/colinux-devel > |
From: Brian Dunford-S. <bh...@ea...> - 2004-05-09 16:37:57
Attachments:
install_colinux.nsi
|
The following section of this message contains a file attachment prepared for transmission using the Internet MIME message format. If you are using Pegasus Mail, or any other MIME-compliant system, you should be able to save it or view it from within your mailer. If you cannot, please ask your system administrator for assistance. ---- File information ----------- File: install_colinux.nsi Date: 9 May 2004, 10:56 Size: 12677 bytes. Type: Unknown |
From: Martin K. <ka...@po...> - 2004-05-12 21:36:46
|
Hi, i can't see the point, why do you want to use sparse tars, when nsis installer is packed with bzip2? it's a better compression, ain't it? is there any reason for this? Regards, Martin Brian Dunford-Shore wrote: > The following section of this message contains a file attachment > prepared for transmission using the Internet MIME message format. > If you are using Pegasus Mail, or any other MIME-compliant system, > you should be able to save it or view it from within your mailer. > If you cannot, please ask your system administrator for assistance. > > ---- File information ----------- > File: install_colinux.nsi > Date: 9 May 2004, 10:56 > Size: 12677 bytes. > Type: Unknown |
From: Brian Dunford-S. <bh...@ea...> - 2004-05-13 04:18:42
|
I have most of the source files for my installer in a zip file available at: http://home.earthlink.net/~bhds/install_CoLinux.zip This file is a little over 4MB. This does not include the two Linux file system image tar files--I don't have space on that site for files that large. It also does not include the resulting install_Colinux.exe--same size considerations and I want to do a little testing first. I patched tar a little more--I fixed the '-C' option to honor Windows drive letter paths. The complete patch is in the zip file and the incremental patch is at the end of this message. Brian Dunford-Shore bh...@ea... ===============tar_chdir.diff================================= *** tar-1.13.orig/src/names.c Sun Sep 28 21:41:12 2003 -- tar-1.13/src/names.c Wed May 12 21:42:53 2004 *************** *** 223,231 **** -- 223,270 ---- name_array = (const char **) xrealloc (name_array, sizeof (const char *) * allocated_names); } + #ifdef __GW32__ + name_array[names++] = make_dos_name(name); + #else name_array[names++] = name; + #endif } + #ifdef __GW32__ + /* Escape the backslashes in a dos file path name */ + char * make_dos_name(const char *name) { + int extra_chars; + char *chr_ptr; + char * dos_name; + int i; + + /* Find out how many backslashes we need to add */ + chr_ptr = name; + extra_chars = 0; + do { + chr_ptr = strchr(chr_ptr,'\\'); + if (chr_ptr != NULL) { + extra_chars++; + chr_ptr++; + } + } while(chr_ptr != NULL); + /* Allocate enough space for the path with the escaped backslashes */ + dos_name = (char *) + xmalloc (sizeof (char) * ( strlen(name)+extra_chars+1)); + /* Escape the backslashes */ + chr_ptr = name; + for(i=0;*chr_ptr != '\0';chr_ptr++,i++) { + dos_name[i] = *chr_ptr; + if (*chr_ptr == '\\') { + dos_name[++i] = '\\'; + } + } + dos_name[i] = '\0'; + return dos_name; + } + #endif + + /* Names from external name file. */ static FILE *name_file; /* file to read names from */ *************** *** 491,497 **** -- 530,540 ---- if (!chdir_name) FATAL_ERROR ((0, 0, _("Missing file name after -C"))); + #ifdef __GW32__ + if (chdir_name[0] != '/' && chdir_name[1] != ':') + #else if (chdir_name[0] != '/') + #endif { char *path = xmalloc (PATH_MAX); *************** *** 593,598 **** -- 636,642 ---- namelist = NULL; } if (cursor->change_dir && chdir (cursor->change_dir)) + FATAL_ERROR ((0, errno, _("Cannot change to directory %s"), cursor->change_dir)); |
From: Brian Dunford-S. <bh...@ea...> - 2004-05-13 00:33:06
|
> Hi, > > i can't see the point, why do you want to use sparse tars, when nsis > installer is packed with bzip2? it's a better compression, ain't it? is > there any reason for this? > > Regards, > Martin The point of the sparse tars is to install a file system and swap device that is large enough for real work (6GB and 2GB respectively) without really using 8GB of disk space on the installed system. You could compress the files on disk, but that usually fragments your NTFS partitions, is slower, and would be a pain to do from the installer. With sparse files installed, someone can try using Linux with only 100-400MB of disk space used and with a five minute install. I think this combines with the unprecedented access Cooperative Linux gives to open to a whole new group of people easy access to trying and using Linux without a major investment (no new hardware/spare computer, etc). Also for those wanting to learn Linux, you just: install CoLinux, screw around with administering it as root, screw it up, and just reinstall to get a working version again. BTW the 6GB was not picked randomly--a full install of Fedora Core 2 (yeah, I know, I'm anticipating ;) ) is currently 5.5GB. The reason I use tar instead of bzip2 and the sparsify program, is that tar records the holes when it creates the archive, not when it unpacks it. This results in much speedier installations--it doesn't even process the data that is zero while unpacking--it just does a file seek! It took about 30 minutes to make a 6GB file sparse on an Athalon 2600--it takes less than five minutes for the full install of 9GB of sparse files on even a slower machine. Brian Dunford-Shore bh...@ea... |
From: Bill C. R. <do...@fr...> - 2004-05-13 04:36:12
|
Do you really save any filesystem space with NTFS? Certainly it is much faster to create a sparse file: i.e. dd if=/dev/zero of=foo bs=4M seek=1024 count=0 is much faster than dd if=/dev/zero of=foo bs=4M count=1024 but either way Windows will still report the same amount of disk used when you are done. As I understand NTFS, it reserves the disk space used for filesystem holes... I do not believe VFAT supports file system holes at all. Bill ----- Original Message ----- From: "Brian Dunford-Shore" <bh...@ea...> To: <col...@li...> Cc: "Martin Kanich" <ka...@po...> Sent: Wednesday, May 12, 2004 8:33 PM Subject: Re: [coLinux-devel] Re: Installer for CoLinux > > Hi, > > > > i can't see the point, why do you want to use sparse tars, when nsis > > installer is packed with bzip2? it's a better compression, ain't it? is > > there any reason for this? > > > > Regards, > > Martin > > The point of the sparse tars is to install a file system and swap device that is > large enough for real work (6GB and 2GB respectively) without really using 8GB > of disk space on the installed system. You could compress the files on disk, > but that usually fragments your NTFS partitions, is slower, and would be a pain > to do from the installer. > > With sparse files installed, someone can try using Linux with only 100-400MB of > disk space used and with a five minute install. I think this combines with the > unprecedented access Cooperative Linux gives to open to a whole new group of > people easy access to trying and using Linux without a major investment (no new > hardware/spare computer, etc). Also for those wanting to learn Linux, you just: > > install CoLinux, > screw around with administering it as root, > screw it up, > and just reinstall to get a working version again. > > BTW the 6GB was not picked randomly--a full install of Fedora Core 2 (yeah, I > know, I'm anticipating ;) ) is currently 5.5GB. > > The reason I use tar instead of bzip2 and the sparsify program, is that tar > records the holes when it creates the archive, not when it unpacks it. This > results in much speedier installations--it doesn't even process the data that is > zero while unpacking--it just does a file seek! It took about 30 minutes to > make a 6GB file sparse on an Athalon 2600--it takes less than five minutes for > the full install of 9GB of sparse files on even a slower machine. > > Brian Dunford-Shore > bh...@ea... > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: SourceForge.net Broadband > Sign-up now for SourceForge Broadband and get the fastest > 6.0/768 connection for only $19.95/mo for the first 3 months! > http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click > _______________________________________________ > coLinux-devel mailing list > coL...@li... > https://lists.sourceforge.net/lists/listinfo/colinux-devel > |