TheJerk

Thanks. I haven't really spent much time looking at AutoIt, so I guess this is the motivation I need. Thanks!

Sorry to gravedig, but this is the first thread I was able to find regarding the silent install of Audition. My ?: is there a way to pass along the serial # during the silent install?

Just curious, but what's the status of the next release?

I really meant no disrespect by my post, so let me clarify. I know writing a manual's no easy chore. And more often than not, programmers are NOT writers and vic versa. It's usually better that if you want a good manual written, you give the responsibility to someone who's good at writing them. Not always a plausible solution, I know.

Actually, you want to integrate it into pro.msi or proplus.msi (depending on which you have). See this for details.

Wow, talk about topic derailment. I agree with nujackk. Look, I've been programming HTML, PHP, etc., etc., etc. for quite some time now. But it's not the issue of whether or not examples are easy to follow or the directions are user friendly for me - follow the common standard if you're going to write documentation. Any type of writing has, since the beginning of the age of reason, had three common elements, and were always more or less in order: beginning, middle, end. In the case of this manual, who's to say which is which? My $.02, not that it matters. Honestly, I don't have time to figure out the documentation or how this application works, so yes, I'll be moving on. But you asked the question....

Thanks, BtS.

First, let me just say that this forum is HUGE! There's so much information going in and out of here, it's a project to search for answers in and of itself. So let me apologize ahead of time since I'm sure this was answered at some point in time. The reason I'm stopping my search, though, is because I'm sure this is something everyone with little experience doing this sort of thing would like to know, so I thought perhaps it would be a good idea that if I receive an answer, you might want to sticky this. Ok. Here's the question: I have Office XP without any updates applied. I have downloaded SP3 and all updates thereafter. If I follow the directions in the unattended tutorial, I end up with prompts after the first update asking me if I'd like to overwrite some files. It appears that these are the same files (update installers, etc.). However, wanting to keep myself from errors as much as possible, I thought it best to consult this huge wealth of information for someone who's already dealt with this issue. List of files to overwrite: ohotfix.exe ohotfixr.dll ohotfix.ini So I'm right about these only being installers, right? If so, do I need to edit anything in order for them to work on all updates? Here's the contents of the ohotfix.ini file from sp3: ; Microsoft Office Hotfix Installer ohotfix.exe information file ; ; This file contains the settings that can be modified by the user to control ; the behavior of ohotfix.exe and the Windows Installer service. ; ; If this file is found in the same directory as ohotfix.exe, it will be used ; to set ohotfix.exe's behavior. If this file is not found, the following ; default settings will be used: ; ; IsNormalUpdate=1 ; AdminUsesShortFilenames=1 ; AdminPath= ; MessageTitle= ; CopyFilesToRerun=1 ; ShowSuccessDialog=1 ; RunSetupWatson=1 ; RequireAllPatchesNeeded=0 ; RequireAllProductsAtMinVersion=0 ; MinMsiVersion= ; UpgradeMsi=0 ; MsiUpgradeURL= ; MinProductVersion= ; OHotfixLogLevel=v ; MsiLogLevel=v ; OHotfixUILevel=n ; MsiUILevel=n ; RebootInQuietMode=0 ; FeatureToCheck= ; ; All of the fields are required, all of the fields with a value specified ; above must have a value, and all of the values must be valid. Otherwise, ; ohotfix.exe will shut down. [OHotfix] ; Ohotfix.exe can apply both normal/client updates and administrative updates. ; 1 = This is a normal/client update. ; 0 = This is an administrative update. ; IsNormalUpdate=1 ; In an administrative update, the names of the files being updated can use ; either the short format or the long format. ; 1 = Use short filenames (must be used for Office). ; 0 = Use long filenames (must be used for Visio). ; AdminUsesShortFilenames=1 ; In an administrative update, the path of a valid Windows Installer ; administrative package must be specified (for example, c:\adminimage\visio.msi). ; The path can be specified here using AdminPath; or, if no path is specified ; here and OHotfixUILevel is set to n, ohotfix.exe will prompt for a path. If ; no path is specified here and OHotfixUILevel is set to q, ohotfix.exe will ; shut down. Ohotfix.exe will also shut down if OHotfixUILevel is set to n ; but no path is specified at the prompt. ; AdminPath= ; The title displayed in ohotfix.exe message boxes can be specified. If no ; title is specified with MessageTitle, a default title is used. To display ; no title, specify a space for MessageTitle. Ohotfix.exe messages are only ; displayed if OHotfixUILevel is set to n. ; MessageTitle=Office XP Service Pack 3 (SP3) ; If a system restart is required but more patches need to be applied, ; ohotfix.exe can copy the necessary files to a safe location, restart, ; and then run itself again to apply the remaining patches. ; 1 = Copy the files to a safe location and try to restart and rerun. ; 0 = Do not copy the files and do not try to restart and rerun. ; CopyFilesToRerun=1 ; A final dialog can be displayed to indicate that the update was applied ; successfully. This dialog will only be displayed if ShowSuccessDialog is ; set to 1 and OHotfixUILevel is set to n. ; 1 = Display the success dialog. ; 0 = Do not display the success dialog. ; ShowSuccessDialog=1 ; Microsoft's Setup Watson can be used to report to Microsoft certain ; errors encountered during the update process. Setup Watson displays dialogs, ; which will appear even if OHotfixUILevel is set to q. ; 1 = Use Setup Watson to report errors to Microsoft. ; 0 = Do not report errors to Microsoft. ; RunSetupWatson=1 ; Some updates require that all of the patches be either needed by or already ; applied to the product being updated. ; 1 = Require that all of the patches be either needed or already applied. ; 0 = Do not require that all of the patches be either needed or already applied. ; RequireAllPatchesNeeded=0 ; Some updates require all of the products being updated to be at or above ; a certain version (for example, at or above the SR1 level). To invoke ; this requirement, RequireAllProductsAtMinVersion must be set to 1 and ; MinProductVersion must specify a valid product version. If ; RequireAllProductsAtMinVersion is set to 1 but MinProductVersion is not ; set, ohotfix.exe will shut down. ; 1 = Require all of the products being updated to be at or above the ; specified version. ; 0 = Allow the update to be applied regardless of the products' versions. ; RequireAllProductsAtMinVersion=0 ; If RequireAllProductsAtMinVersion is set to 1, MinProductVersion must ; specify a valid product version using the standard version format (for ; example, 10.1.0). ; MinProductVersion= ; Some updates may require that the Windows Installer service be at or above ; a certain version (for example, at or above 1.1.0). Ohotfix.exe can check ; the Windows Installer service's version and shut down if the version is too ; low. To invoke this checking, use MinMsiVersion to specify a valid Windows ; Installer service version. ; MinMsiVersion=2.0 ; If the Windows Installer service's version is checked and is found to be too ; low, ohotfix.exe can launch a Web site from which the Windows Installer ; service can be upgraded. To enable this, UpgradeMsi must be set to 1, ; MsiUpgradeURL must specify a valid URL, and OHotfixUILevel must be set to n. ; If UpgradeMsi is set to 1 but MsiUpgradeURL is not set, ohotfix.exe will ; shut down. ; 1 = Launch the upgrade Web site if the Windows Installer service's version ; is too low. ; 0 = Do not launch the upgrade Web site. ; UpgradeMsi=1 ; If UpgradeMsi is set to 1, MsiUpgradeURL must specify a valid URL that is 259 ; or fewer characters in length (for example, www.microsoft.com). ; MsiUpgradeURL=http://go.microsoft.com/fwlink/?LinkId=20610 ; Log files are always created to record the progress of ohotfix.exe and ; the Windows Installer. ; v = Log all ohotfix.exe actions/messages. ; n = Log only normal ohotfix.exe actions/messages. ; OHotfixLogLevel=v ; v = Log all Windows Installer information, including the verbose information ; (/L*v+). ; n = Log Windows terminal properties and Windows Installer status messages, ; nonfatal warnings, startup of actions, and error messages (/Lpiwae+). ; MsiLogLevel=v ; The user interface level can be set for both ohotfix.exe and the Windows ; Installer service. ; n = Display ohotfix.exe messages. ; q = Do not display ohotfix.exe messages. ; OHotfixUILevel=n ; n = Display the basic Windows Installer user interface. ; q = Do not display any Windows Installer user interface. ; MsiUILevel=n ; If OhotfixUILevel is set to q and IsNormalUpdate is set to 1, ; Ohotfix can automatically reboot the computer if a reboot is required ; to complete the installation. ; 1 = Automatically reboot the computer if a reboot is required in quiet mode. ; 0 = Do not automatically reboot the computer if a reboot is required ; in quiet mode. ; RebootInQuietMode=0 ; Updating can be blocked if a product's feature is not installed locally ; (for example, do not apply an update if the Program_Files feature is not ; installed locally). This can be used to prevent mixed local/run from ; source configurations. To invoke this capability, specify the name of a ; feature found in the products being updated. This check is performed only ; for normal/client updates, not for administrative updates. ; FeatureToCheck= I appreciate any help I get on this. And I'm sure I won't be the only one. EDIT: Nevermind... I'm dumb. Apparently the hotfix files are unnecessary and can be ignored (feel free to correct me if I'm wrong). @Mods: feel free to delete this post. LOL

LOL Best thing to do is write down each missing file as you go through the install. Then pop back into your source and delete them using "find". BTW, thanks to you and Erik for discussing this. You just solved a problem I was having with a missing file. LOL

Ok, I admit I haven't searched for an answer on this, but my assumption is that I wouldn't be able to phrase anything that could possibly give me any results. Ok, here's the problem. Windows seems to think my sound card, the Hercules Gamesurround Fortissimo III 7.1, is a Conexant-compatible sound card. Why's this a problem? Well, because the drivers for this particular card, from the manufacturer, aren't signed. The drivers that were on the install CD weren't signed either. As a matter of fact, none of the drivers I've seen for this device have been signed. So what ends up happening is that Windows assigns the device a name (conexant compatible sound device, or something like that), but won't install any drivers. I tried using the drivers from CD method, the driverpacks method (same principle, right? either way, I know these drivers aren't in the driverpack) as well as nLite. So far, nothing's worked. I thought about using the winnt.sif file, but then it occurred to me what the problem was (see above). My guess is, no matter how I tell Windows where the drivers are, it's not going to install them unless I force it. So, aside from using runonceex, any suggestions? I was thinking about seeing if I can remove those particular drivers from the CD (the ones that make Windows think it's something when it's not), but I wouldn't know exactly how to go about doing that.

Thanks. I'll check it out.

I haven't played the game in a while, so I'm not sure how helpfull I'll be. But... How far along are you? Just need to refresh my memory on what's available and when, and then I might be able to help you out.

First, let me say that I tried searching, but had no luck finding anything. Ok, I have a Hercules Fortissimo III 7.1 which uses the Crystal Sound Cards driver pack. I extracted the EXE I downloaded from the Hercules website and show 8 files: data1.cab, data1.hdr, data2.cab, ikernel.ex_, layout.bin, setup.exe, setup.ini and setup.inx. As you can see, there's no INF file. First, so I may avoid this in the future, what would be the command line syntax to get the switches from setup.exe? I tried using the help switch (both /? and -?) and both times I didn't receive any answers. It would just run the setup file (and then ask me if I want to remove my currently installed drivers). I also tried to extract the cab files, but Winzip, WinRAR and 7zip don't recognize the files. Setup.ini only contains this information: [Startup] AppName=Crystal Sound Cards ProductGUID=A106671F-3741-4F3B-B39D-AB7E2F1CE81B [Languages] Default=0x0009 count=7 key0=0x0013 key1=0x0009 key2=0x040c key3=0x0007 key4=0x0010 key5=0x0816 key6=0x000a Also, nLite doesn't accept drivers without INF files. So my assumption is that I would need to use runonceex inorder to install these. Is there no other way? I honestly would love to see this driver installed along with all of my other drivers, and only if it's necessary (so, let's say I remove the card, I don't really want to install the drivers for it at that point).

I'm already working on incorporating it into my UXP, but if you'd like to look this up for future reference: The name of my card is Hercules Gamesurround Fortissimo III 7.1. It's a 7.1 channel card and is the best I've had to date. The drivers can be found here: http://ts.hercules.com/eng/index.php?pg=vi...23&pid=18&cid=1 There's several products for the Hercules brand, just in case you're inclined to look into it. BTW, I appreciate everything you've done. Thanks so much for all of the hard work.

Thanks. I had actually forgotten about the XP dual boot issue, but fortunately I picked up the info on properly editing it a couple days ago (on a seperate issue, actually). I'd disconnect the HD, but that's too much work for me.

Thanks for the welcome and quick reply. So let me ask you, would it be a good idea to test it, then, on a second boot partition? That is to say, perhaps remove the VMWare virtual disk, partition the same amount of space for a real OS and try actually installing my unattended XP disc to it? The size of the disc at this point, I could fit it onto a CDRW, so writing an actual disc isn't a problem for me. Just wondering if that would be the best way to be absolutely sure that the integration worked.

Hey, guys. Been hanging around here for about a week now trying to learn how unattended CDs are made. The last 3 days, actually, have been used trying to locate a solution to my current problem... the Si3112r drivers. Now, it has just come to my attention thanks to VMWare that the virtual SCSI used by VMW is NOT the same as the actual SATA controller I have in my system. Is this correct? I went so far as to attempt hitting F6 and using a floppy image of the Virtual SCSI drivers provided by VMW, and for the first time I was able to make it past the initial setup of the XP-setup. Now, let me make it clear what I've done up to this point: First, I started off by doing everything the manual way following the guide on this site (unattended.msfn.org). Talk about getting myself into a heap of trouble. That's a great way to get yourself confused if you've never done this stuff before. Anyhow, I installed the SATA using the methods detailed in the guide and gave it a go (created test image, used VMWare). No luck. I then started over, but this time only followed the guide until the point of integrated the SATA driver. At that point, I used the Driverpacks (I actually tried all of the driver packs, following the instructions included with them). Again, no luck. Again, I started over. This time used just the MassStorage pack. Nothing.... I made several attempts with different solutions that were posted on these forums. Nothing. Finally, I changed the options in VMW to use Windows XP as opposed to Win2k (as was directed by the guide on this site) and when I started it up, I was notified about the SCSI driver issue common with VMW and XP. I downloaded the floppy image, used it as directed, and the setup screen finally made it to the partition options. The actual error I was getting was that no hard drive was found, by the way. So, here's my question: Besides wanting to know if the Si3112r drivers just plain suck (which is my opinion at this point), is there any way to know with VMWare if I'm integrating these stupid drivers properly? Oh, and as an end note and just to be clear. I've spent the last three days going through the search function on this site trying to find a solution. There's a ton of information regarding the Silicon drivers, but unfortunately I get the "glazed over" look on my face after reading half way through most of it. And at no point was I able to figure out exactly the answer to this particular question.