simply_simon

Update: All the domains beginning "WWW" can be scrapped as just the end of the domain will do. Anything in "domain.com" etc will be in restricted sites zone. So that'll shrink it a bit. I'm working on a test project for an Auto Updater for the .reg file. At the mo, it's just a simple check between filesizes and to see if the file actually exists. Then it's just a case of downloading the file direct and merging the file as necessary. I need to make a few adjustments before I can post a tester, but this would be an ideal solution for some. Give me some feedback on whether you'd be interested or not.

Giving it a try now. I've always been an advocate of using the "Restricted Sites" method (REG) to block sites as opposed to hosts, because you can see the offending sites for what they are. The registry entries look fine to me so far, I'll let you know. In the meantime, I hope to be able to find a decent mirror for the blocklist AND write an AutoIt script to take care of updating.

What I do normally is to use a zero value for the shutdown timer and use a program called "sleep.exe" to pause the system whilst programs are stopped. I know it doesn't look as cool as a timer counting down the seconds and I don't use DOS much either as I have my own Application Installer which replaces the DOS shell. I guess you could use the "sleep.exe"program (Link is somewhere on this site. Been a while since I last downloaded it) in combination with simple echo commands in your batch to simulate a timer. For example: @echo off CLS echo "Rebooting in 2 seconds..." sleep.exe 1 CLS echo "Rebooting in 1 second..." sleep.exe 1 CLS echo "Now Rebooting." shutdown.exe -r -f -t 00 That code is a little clunky for a three minute countdown and I'm sure there are much better ways of doing it (With some sort of loop), but at least it gives you an idea. I used the CLS command to clear the screen and make it appear as though the timer is just counting down on the same line (A throwback to my old BBC Basic days at school).

Generally, the developement of these unattended recovery partitions would be done using the OEM preinstallation kit, but it should be possible to make a hard drive based recovery partition. Once created it's a matter of editing the boot.ini file to modify the boot options. Lots of work though....

As promised, here are a few lines from my preinst.ini file to give some working examples: <lbl>Installing MS Visual Studio <cmd>*\Install\MSVS\Smsinst.exe /k (SERIAL REMOVED) <cmd>runhiddenconsole.exe /w sleep 500 <lbl>Installing Nero 6 Ultra Edition <cmd>regedit /S *\Install\Nero\register.reg <cmd>*\Install\Nero\setup.exe /silent /noreboot <lbl>Installing K-Lite Mega Codec Pack <cmd>*\Install\KLM\klmcodec147.exe /verysilent /LoadInf="klmcp.ini" <lbl>Installing MS Office 2003 <cmd>*\Install\Office\setup.exe /qb- TRANSFORMS=Unattended.MST <lbl>Installing 7Zip <cmd>*\Install\7z.exe <lbl>Installing Alcohol 120% <cmd>regedit /S *\Install\alcohol\prerun.reg <cmd>*\Install\alcohol\alcohol120.exe <cmd>*\Install\alcohol\AlcReg.exe <lbl>Restarting Your Computer..... <cmd>runhiddenconsole.exe /w *\Install\cleanup\cleanup.bat I have been reluctant to use bare MSI files, as they seem to mess up somewhat, so I generally package them with 7Zip and use the msistub.exe to launch the MSI's within. Of course, you could run them unpackaged with either StartX.exe or msistub.exe (Best placed in the system32 folder). You will note that you can use as many CMD lines per install as you want. The most I have used so far is three but it's unlimited, as the program just parses each line and looks for the tags. If it doesn't recognise anything, it will just skip to the next line.

I've tried running this way before using the same net boot disk. It may be to do with the location that XP is being run from. If you check out this page http://www.quepublishing.com/articles/arti...0&seqNum=6&rl=1 one of the switches is to specify where the temporary files and the installation goes. You could try that, specifying the drive letter you want. In the days of old, there would have been a switch to disable the error reporting (Disk space, memory etc.), but this no longer seems to be the case, where there is only a limited DOS support.

Well let us know how you get on with it....

Requires some work, but if a progam or script could locate a date code in the registry, it could then look for a file ending with a date code later than itself to consider it an upgrade. One such example would be to append a reverse date to the filename (Eg. Domain_Blocklist_060305.reg if it was made 5th March 2006). You could put a date into the registry almost anywhere. I have no experience with AutoIt, but in a Visual Basic Scenario, it's just a case of a couple of API calls. A simple For/Next loop would check for every date from the date in the registry upto the current date and see if a file existed on the server. If it did, it would be downloaded and executed. You could have the updater run scheduled or at startup. Voila!! An automatically updating security tool!

I've been checking out KTools and I'll take nothing away from it, because it's an excellent app. There are one or two differences in the way the two progs work to be honest and it's really just a case of trying out both and seeing which works best for you. At present, I'm just testing the water, so to speak, by finding out what people want to use for their installs. The main 'selling' point of my app is it's simplicity in coding, but with a good deal of versatility. Also, the locating of the script file is an idea brought up by one of my 'guinea pigs' during initial tests, so it's just a case of listening and catering for what people want. I'm not saying this is any better than anything else out there, just an extra choice really.

This method is way better than using the HOSTS file in my opinion. It puts the relevant domains into the restricted zone. You will still have limited access to these sites but will not be able to download any files from them (Nor will they be able to force any downloads on you). This is most handy with malware sites, such as Winfixer (Which as I said before, has an exploit that is rather difficult to get rid of). The HOSTS file is a different kettle of fish altogether, in that it blocks a domain altogether (Or rather, sends your computer to 127.0.0.1 to look for the domain, which of course won't be there). Just my two pence worth!!!

I'll vouch for that! The update pack along with nLite will save you tons of extra headaches. Not only that, but the updates are slipstreamed with the installation. In addition, .NET Framework 2 is now an integral part of my unattended installation. So it's there when I need it. It's wothwhile putting that on your CD too!

Could there be a registry entry and a version number to be added to the reg file in future to denote current version perhaps? Possibiltity exists there for a good security tool.

Absolutely no problem. I think most people will want to avoid WinFixer if they can. Took me three days and an eventual reformat to rid my brother-in-law's PC of this wonderful piece of malware. In response to your updating dilemma, I'll look into the possibility of constructing some kind of updater over the next few days using VB6. It may be that there'll need to be some sort of manual control over it, in the case of a non-permanent internet connection.

I think these ones should be added at a later update too. They are additional domains that are associated with the WinFixer Exploit. amaena.com Win-anti-virus-pro.com Win-antivirus.com Win-virus-pro.com Winantivirus2005.com Winvirus2005.com

Using nLite and RyanVM's updates, it should all fit. In any case, nLite will help you strip a whole lot of stuff that you don't want from your installation.

This is it! After several attempts to get it working properly, I finally have a release-able version. Screenshot below: Basically, it's just a script based installer that calls up your installs one at a time based on what is entered into the script file. The syntax is very much batch/RunOnceEx orientated, so it's familiar territory to those who normally use those methods. It has a nice clean GUI interface, so it's much tidier than a batch file... and if you have LOADS of installers, much smaller than the RunOnceEx window. Here's the biggy though, you can put the script file into the root of ANY drive letter, and the program will find it (Program itself can be run from any location you want) and then run your installs from that location. This is very handy if you want to run the installs from a network drive. You can map a drive letter to a network resource using the 'NET USE' command and put your script file there. The script uses a Wildcard system to denote the drive letter, so it makes the code far more portable between different installation types. This program will not be for everyone. If you want preselectivity for your software, this will be looked at for a future release. If you want lots of eye candy, there are several prettier methods out there, such as WPI for example. This progam caters to those that want the job done, quickly and simply, with the minimum of fuss, but with a nice looking end result. I've released it under the GPL, so the source is available for you to muck around with if you think you can improve on it at all (You'll need VB6 to compile). Examples of the scripting are included in the archive, but I will be posting some more later on. Program and source are attached. The program is also available from here. Application_Installer.rar PreSource.rar

Well I don't know how your tests have gone felix, but I have now done three tests with the Virtual PC and I think it's now starting to look like a proper program. All 35 installers worked on my last run, although I'm still struggling with the quotation mark placement on MSI files within the script file, so I used 7Zip installers instead (I'll have to have a play with a couple of combinations of code, so I can see how it works). That said, the WildCard implementation works great and I can now REGEDIT files from the install directories, which I'm totally glad about. I am going to test a little more over the weekend. Once I've worked out the MSI thing, I'm going to start a new thread and post all my findings up to now (5 pages is getting too long).

I'm glad to have a good guinea pig for this project (More needed please!!!). I have now added a feature to parse the commandline for an alternative filename for the INI file. If no name is specified, the default is preinst.ini. There's also a couple of code cleanups and I've released the project under the GPL, so it's now totally Open Source. I'm still getting strange results from some of the msi installers, particularly where large numbers of quotes are used. I'm trying to see if using single quotes would work. Probably be a couple of days before I get a new test up and running though.

Suggestion taken on board, thank you. I have one for you too, if you want it... Avoid the need for StartX by making 7Zip installers. Makes the configuration of everything else much simpler. I just made one for VMWare that includes the serial, all nicely packaged into one switchless exe file.

I personally use nLite, but that's just because I haven't tried anything else yet.

@Felix. OK i've put in the WildCard function now and updated the link. You have made some good comments about the program so I thought I'd continue by answering some of them. Firstly, You mentioned locating the CDROM. The program already does this by looking for the preinst.ini file. I've even had this on a network drive and ran installers from there, so it's even more versatile. With regards to the rest of your suggestions, I would prefer to keep the INI file as close to RunOnceEx syntax as possible (Barring the WildCard thing of course), so I'm leaving the rest as-is for the time being. Take a look at it and see if you can figure it out. I tried duplicating your install, using these commands and they worked like a charm: <lbl>VMware Workstation 5.5 <cmd>startx /wait "msiexec /i *\apps\vmwarewkst\VMware_Workstation.msi /qb-!" <cmd>REGEDIT /S *\apps\vmwarewkst\register.reg StartX is in the system32 folder in this example. Basically, the program now has a command to replace any instance of the '*' with the drive letter of wherever it finds the 'preinst.ini' file. I think I may have to start a new thread soon. This one's getting a bit long.

@Felix. You still have some syntax wrong there. If you're using a <dos> line, you will have to give an ABSOLUTE path to your end file (You can't just REGEDIT a file from the command line without telling the command line where that file is. You could try running the regedit from the <prg> line. I haven't tried it yet) For Example, the code <dos>REGEDIT /S apps\moviegear\register.reg will not work, because the <dos> line works directly from the system. It will try to find the 'apps' folder in the 'system32' directory. It's an unfortunate limitation I'm afraid. Hopefully someone else could crack something a little better. (There could be a REGEDIT workaround. Try copying regedit.exe from the system folder into your app's install directory and call it from <prg>. Again, not tested) Of course, if you know the location of your 'apps' file (EG %CDROM%) you could always put <dos>REGEDIT /S %cdrom%\apps\moviegear\register.reg Unfortunately the problem arises out of the principle of the CD-ROM not always being in the same place. A complete workaround would be to put all the Installs to a folder on the system drive and run them from there, but this isn't ideal for everyone. UPDATE: I may have found an answer, but it'll require some more coding. I'm going to simplify things and get rid of the dos command. I'll use a wildcard (Maybe an asterisk *) to specify the root location (So you'll get this. <cmd>REGEDIT /S *\apps\moviegear\register.reg I think <cmd> would be a better tag than <prg>. The * will represent the location of the 'preinst.ini' file and therefore, the root of your installation. I'll code this up tomorrow (Doing the Math tonight). Just to add to my earlier dilemma, my errant MSIs still didn't install properly until after rebooting, so I've come up with another plan. I've compiled another EXE, this time called 'preins2.exe' and changed the coding to call for 'prein_2.ini'. What this means, is that I am now able to run a second instance of the program after the reboot (called with RunOnceEx just like the last one) and install the prorams that were giving me grief... Well that's the plan anyway. If I'm successful, I'll update the download accordingly.

@felix. Was trying not to complicate things too much, which was why I suggested using a batch file for Multi-line installs. Basically, the <prg>line runs from the location where the preinst.ini is. The <dos>line runs from the system (Exactly the same as if you'd used "Start\Run" or opened a command prompt) The DOS commands are only needed if you need to run a command from the system (Such as taskkill). I suggest the easiest way to attack this would be to put all the commands into a CMD or a BAT file in the app folder and call it run.cmd os something like that. Then just run that instead. One of your examples for a CMD file is below... @echo off start /wait dreamweaver8.msi /qb-! start /wait patchpackage.msp /qb-! start /wait license.exe exit You'd then put two lines down for your config. <lbl>Macromedia Dreamweaver 8.01 <prg>apps\dreamweaver\run.cmd I know that batch files seem a little messy, but I coded the program so that anything it starts is automatically minimized. Of course, you can hide the Command windows with CMDOW if you like, but at the RunOnceEx stage, you'll barely notice them anyway. Please tell me if you need any other help. EDIT: Just to add, I've been experiencing difficulties installing certain msi based installers. These seem to exit with an error like "Please go to the Control Panel to configure components". Once rebooted, I ran the same installers and they worked perfectly. So I'm now doing another run with a shortcut to the preinst.exe file in the startup folder instead of RunOnceEx stage, so that it starts once the full Windows GUI is loaded (I'll delete the shortcut before rebooting, or it'll start every time windows loads). I'll let you know how it progresses.

@ Muiz, If you're still there, you asked at the beginning, how you'd do that ad-aware thing yeah?? This would be what you'd now get: <lbl>Installing Ad-Aware Pro SE V1.06 <prg>Software\adaware\adaware.exe /S <dos>taskkill /IM Adaware.exe /F <dos>taskkill /IM hh.exe /F <dos>taskkill /IM Ad-Aware.exe /F <prg>Software\adaware\defs.exe <prg>Software\adaware\dutch.exe <prg>Software\adaware\sites.exe <prg>Software\adaware\Lavasoftprefs.exe Would that maybe interest you? Try it and see if it goes for you.

I had already figured on a font tag, but not colours. The background's a bit much to mess about with right now, but changing the colour of the progress bar is another option I'll sort. Also I'm going to allow the user to edit the title of the window and the text labels too. The coding's a lot easier than I expected, so it shouldn't be too long before I have a version done. With regards to Vista, Microsoft have apparently stated that it would be backward compatible with older software, so hopefully it will still continue to support the runtimes for VB6. As for VB.NET, hopefully Vista will be rolled out with the runtimes already installed because you'd have to RunOnceEx twice in order to use a VB.NET program to install applications like we are with XP. UPDATE: Okay, here's what I've done. I've left the font colours as-is for now, but you can now change an awful lot of what you see in the interface. As promised, I've brought in the tags and they seem to work rather well. I've released this one for download so see if it improves on the last one at all. Here is what the 'preinst.ini' file now looks like. Application Installer Configuration File --------------------------------------- #The 5 tags below are crucial for the program to run #Edit by all means but do not delete or comment them out!!! <TiTle>Finalizing Windows Install <Text1>Windows Is Installing Your Software. Please Wait..... <Text2>Current Action.... <Font>Times <ProgColor>blue --------------------------------------- #Any combination of tags <lbl> <prg> or <dos> can be used below, #but every <lbl> tag will be counted when updating the progress bar. #KEY: <lbl>Text label of action (EG 'Installing Blah Blah'). # <prg>A program or command to be run from this location. # <dos>The same as using Start\Run (EG. Terminate). # <lbl>Example(1) <prg>Rawritexp.exe <dos>calc <lbl>Example(2) <prg>Rawritexp.exe <dos>calc I think it should make it clearer as well.