Martin H

Relokick 1.4a ©1994 Galahad of Fairlight: http://cd.textfiles.com/zoom2/utilities/wb/relokick/ About ReloKick v1.4 from another page:

...Just wanted to add that i've just tested with the MS-DOS batchfile extension i.e.: .BAT(as oppossed to NT command scripts CMD extension), and still the same result i.e. "waiting" is enabled by default! That's pretty obvious as the NT command processor cmd.exe also runs those files, which actually kinda surpriced me, as i thought that the MS-DOS command processor command.com would run those, but i've never before runned .BAT files on a NT system, since I generally always preffer to use the "correct" extension, so that's why i didn't knew anything about it... Anyway, could the people that posted that i was wrong please re-test by following my previous instructions and post back, thanks!

As Yzöwl correctly stated, then if using the start command without the '/wait' parameter from a NT command script, then "batch-mode-waiting" is over-ridden, so when testing, then use: 'appname.exe /switch' Vs. 'start "" /wait appname.exe /switch' ,and not 'start appname.exe /switch'... This then also means that if you e.g. want to run an app e.g. minimized from a NT command script, by using the 'start' command, then you can use the '/wait' parameter to enable waiting, as the 'start' command over-rides that without it, but again, i was stating that 'start "" /wait' was redundant in NT command scripts for the use of enabling waiting, as waiting is always enabled by default for NT command scripts, but not that the 'start' commands '/wait' parameter was redundant...

Yes, GUI is keyword as console apps and internal cmd commands always have waiting enabled(in the NT command processor!)... Still, the 'start /wait' command is IMHO only meant for console usage and not from NT command scripts... Look at the following scenario: Try to run a big app like VMware or dotNET-v2.0 silently from a NT command script without 'start /wait'; what happens; waiting is enabled untill end... Then try to run it from a command prompt this time; what happens; waiting isn't enabled at all, and this "non-waiting" behaviour can then be over-ridden by adding 'start /wait'...

For me then NT command scripts always wait! (if not, then it's because an app starts another process while ending the previous one, and in that case, adding 'start /wait' dosen't help) After having for years noticed that for me, then 'start /wait' or no 'start /wait' didn't made a difference, and then also after having seen the following text yesterday on a technet article about the 'start' command: Source: http://technet.microsoft.com/en-us/library/bb491005.aspx Then i did the following to test it out... Open a command prompt and enter 'notepad' and then minimize notepad and check the command prompt; dose it wait or not; no it dosen't wait.. Now do the same again but with added 'start /wait' and see that it does wait... Then now make a NT command script with the content: 'notepad' and run it and what happens; the NT command script is still open after notepad has started and the NT command script is paused on the 'notepad' line which means that waiting IS enabled from NT command scripts... I have lots of NT command scripts and no one uses 'start /wait'... For example one script starts nLite unattended and silent and through the entire process the script is waiting and only when nLite ends, then the script continues to the next line to make ISO and copy the ISO to backup folder etc.

Everyone, please re-read my post again! I haven't tested with bat, as i'm not interested in that... The correct extension for NT command scripts(which this thread is about!) is cmd and not bat... Also, please understand that i'm not stating that 'start "" /wait' dosen't work, i'm just stating that from a NT command script, then the command is redundant, as "waiting" is enabled by default! Of course it dosen't hurt to leave that command in either, but again, i'm just stating that it's redundant... If an app dosen't finish before the next starts in a NT command script, then 'start "" /wait' will not make a difference whatsoever, and instead e.g. 'ping -n 10 localhost' can be used instead of external 3'rd party tools... This forum, MSFN unattended guide and entire web is filled with statements about 'start "" /wait' will enable "waiting" in CMD files and i'm just trying to end that myth with this thread...

OK, in my own experience, then 'start "" /wait' has never made a difference(just used ping instead when needed i.e. when a process branches out to another one), even though the MSFN unattended guide and many other places states so... However, i thought that it couldn't be right that msft had made a parameter which didn't made a difference, so i was puzzled about it... Now i've finally found out what the deal is about this... the CMD prompt will by default not wait for a win32 gui app to terminate before returning to the cmd prompt again UNLESS it's run from a NT command script! So, this means that the parameter is thought to be used ONLY when running from the cmd prompt and NOT from a NT command script! Check it out for yourself if in doubt... Anyway, just wanted to add that you can all now remove your 'start "" /wait' commands from your NT command scripts, as they are totally redundant...

No, the hotfixes dosen't show up on WU/MU, as they are hotfixes and not updates and comes from xable' site: www.thehotfixshare.net (hotfixes only!). As a sidepoint, i've never understood why HFSLIP insists(like nLite) on using the QFE branch of the updates... Here's what msft states in each hotfix kb article: Also in msft's own hotfix explenation: HFSLIP then incorporates those hotfix fixes for each slipped file in the sourcess folder: Anyway, just my 2 cents... And sorry for off-topic'nes..

Needed??? Hotfixes are fixes for non-widespread, non-critical issues, which is developed fast and hasen't gone through as much regression-testing as the normal updates... Also, since HFSLIP allready is using the QFE branch of the updates, then the files in the updates allready include the fixes from the hotfixes(only for the included files in the updates that is...)

AntiVir is pretty low on system resources compared to many others... No, the free AVs don't use the same engines, and most do allow auto-update /scheduling, like e.g. AntiVir and Avast(both in their free versions...) If you're sick of the popups in the free AntiVir, then you can just run this command after installing it: cacls "%programfiles%\Avira\AntiVir Desktop\avnotify.*" /e /d everyone(now also avnotify.dll needs blocking in addition to avnotify.exe, and hence the 'avnotify.*') Everyone is free to set permissions on files on their OS, so i can't see the above as anything illegal IMHO...

It was a public-domain disc which emulated kickstart 1.3 support for amiga 500+(that model wasen't that widelly used either...) @03GrandAmGT Amiga games dosen't need workbench to be pre-loaded by the user before-hand... not even the "standard-compliant" ones..

Ahh, Amiga - the memmories... That was also my first computer, but didn't used it much for gaming, and i remember trying hard to learn programking assembly language on it(but it was to hard for me, 13 years old about..) Anyway, just wanted to throw in that if your model is Amiga 500+, the one with built-in 1mb instead of 512kb and kikstart 2.0 instead of 1.3, then many games didn't worked, as they werent compatible with kickstart 2.0 and hence, instead of adding a kickstart switcher + kickstart 1.3 in hardware, then there where a floppy-disk that could be loaded before the game which then stayed resident in RAM and would run a big number of the kickstart 1.3 only games... Maybe that is your issue, i dunno... If not, then as jaclaz said, it's probably a damaged disc or a unbootable one... Most Amiga games could nut even be run from workbench, as they'ed show up as NDOS disks, since they used internal routines for everything including disklayout/sector-loading and not the OS API functions

Thanks alot Mimo! You rock, mate!

Here's a pemodify script to fix this by Tomcat76, from back when i had the same issue:

Sorry, but are you absolutelly sure of that? In my experience, it cabs and uses all files except a select few predefines(readme.txt etc.). I've always used DriverCompressor first for that Job(i.e. excluding INF-unreferenced files), but if you're right then that extra step is redundant, which i didn't knew... I haven't used nLite in a while, but i'm pretty sure i remember correctly...

@Tom When i said to you previously that the TZ update worked in HF, then i just checked that the files where updated + checked that a few of the reg-entries from the INFs [Product.Add.Reg] section matched when compared to the registry... However, i've just now found a thread on RyanVM's forum with e.g. this quote from ricktendo64: http://www.ryanvm.net/forum/viewtopic.php?p=100044#100044 Sorry about that...

Addons don't go in HFGUIRUNONCE... If you mean switchless installers(with .EXE extension!), then they are probably made with the moded 7z installer module, which means that you need to first run pemodify on them to fix their headers...

The hive files are just reg-entries in INF format... Just check out FDV's WinXP-SP3 fileset as a refrence... http://www.vorck.com/windows/index.html

@Mim0 Would it be possible to implement using '*' or something else in the ignore lists? I'm reffering to e.g. the lame MRT update(which changes versions each month): +IGNORE H|HF\windows-kb890830-v3.4.exe - No biggy, but just a thought... And again, thanks for all your nice work!

Thanks mate, and sorry for off-topic'ness

According to av-comparatives.org's 2009 summary-report(latest), then 'Avira AntiVir' came at first place on the 'performance/low-system-impact' test. I would personally not buy an AV-product, when both 'Avira Antivir' and 'Avast' gets such good scores on the on-demand detection tests at av-comparatives.org... They both are Win2k compatible... Edit: In the performance-test, then the 'Avira AntiVir' version tested is the non-free one, but i doubt there would be performance changes between the two editions... Also, the malware/spyware engine in the free/non-free versions of AntiVir are the same(according to the Avira forum at least). Edit2: some changes in the above + wanted to add the scores that AntiVir, Avast and AVG got in the latest av-comparatives.org's on-demand test: Avira AntiVir: 99.4% Avast: 98.0% AVG: 94.0% (Note: Not their place in the test-result, but just their scores!)

Yeah, atleast it did with v6.0.1 b55017(i used that as it was the latest lite version from RyanVMs forum). I recall that there where another service added, which i also incorporated into the INF, but i'm affraid i don't have it anymore, as i've changed over to using VirtualBox now instead... Anyway, you can easilly add it yourself i.e. just run 'WIN+R > services.msc', double-click on the other service and note the name at the top and then duplicate it to the addreg and runpostsetupcommands sections following the used syntax...

I'm affraid not, sorry... The CAT file of the driver-package is the file which is WHQL-signed and in that CAT file, then there's checksums of all the files in the driver-package(including the INF file), and when then editing the INF file, then the checksum of that INF file isn't matching the one stored in the CAT file and hence, the driver will not be accepted anymore as a WHQL-signed driver... I believe that a workaround would be to find out which exact name the msft INF for the requested driver has, and then name your own updated drivers INF that way, which then should overwrite the msft INF in the INF folder.

Thanks for your reply, mate! I am unsure what the above exactly means though... "There's a thread in the winlogon process"; gotcha! but when you then say "since the WGA updates...", then is that thread in winlogon also doing the phone home'ing without WGA-N installed? Sorry for being dence Thanks in advance!

The following comparisson goes for both HFSLIP/HFSLIP64 VS. nLite... More updates supported for direct integration(e.g. nLite normally don't support updates with new binaries added, WMP updates for <WMP11 versions are wrongly slipped, DX updates not supported etc.) IE8 slipstreaming. WMP11 slipstreaming. DirectX slipstreaming. WUA slipstreaming. Can be run unattended(nLite cannot when adding new updates to slipstream). No NET dependency. (ligh framework is still 23 megs extra and writes to '%windir%\system32' and to a msft system reg-key). Open-source. etc. etc.