deadbug

Before I forget, you can set a user's picture in the way that I suggested (via a file in the $OEM$ tree) but it has to be a .BMP file. If you are OK with building multiboot DVDs then this is easy. In copy \SETUP\XP\Pro\SP3 to \SETUP\XP\Pro\Finnish and \SETUP\XP\Pro\Turkish. Copy the boot folder twice and patch things as required by flyakite's method and do the same with boot sectors. In the $OEM$ tree under ...\Finnish, change the useraccounts.cmd to do just a Finnish account. Make the corresponding change under ...\Turkish. Leave SP3 doing both. You'll also have to add some additional options to your boot menu. If you use ISOLINUX (as I do) or CDSHELL (as I used to) then you just need to modify the appropriate text file. If you use EasyBoot or something else, then I've no idea, although I presume it must be possible. You could have create an AutoIt script that runs on first boot and asks which accounts to keep. But, to be honest, if you don't choose at installation time (using a multiboot approach) then you can just as easily always install both and then simply delete one before handing the machine over! -- deadbug

A quick update. I managed to get MUI to silently install. I changed cmdlines.txt to this: [COMMANDS] ".\mui\muisetup.exe /i 0410 040b 041f /r /s" "useraccounts.cmd" and moved MUI to $OEM$\MUI. So basically MUI now installs straight off the CD/DVD. I don't know why it didn't work installing from %systemdrive% via cmdlines.txt, maybe it's copied too late or something? Anyway, at least it saves worrying about having to clean up %systemdrive%\MUI. As for pictures, you can add to the set of default pictures by putting suitable pictures in $OEM$\$Docs\All Users\Application Data\Microsoft\User Account Pictures\Default Pictures. This definitely works and I've been doing it for a while. If you have, for example, an account called "Italiano", then you'll find its picture in Documents and Settings\All Users\Application Data\Microsoft\User Account Pictures\Italiano.bmp. So maybe if you copy an appropriate picture there via $OEM$ that might just work? Anyway, some progress at least. The only thing left that I can think of now is how to select the required language without having to do it manually. -- deadbug

It turns out that we have an XP MUI DVD so I've borrowed it. I tried out an Italian/Finnish/Turkish MUI silent install (I thought I ought to have at least one language I understand in there!). It's not all there yet, but here is where I am in case someone else wants to chip in (I'm not likely to play with this again until next week). I create a root for my AIO: \AIO-MUI. In there I place the windows CD in \SETUP\XP\Pro\SP3 ... I happen to have SP3 available but if you don't you need to slipstream SP3 into that directory. (I'm using a cut-down multiboot structure here because it's easiest for me ... you should probably stick to however you are already building your unattended DVD). In $OEM$\cmdlines.txt I have: [COMMANDS] "%systemdrive%\mui\muisetup.exe /i 0410 040b 041f /r /s" "useraccounts.cmd" In $OEM$\useraccounts.cmd I have: net user Italiano italiano /add net user Finnish finnish /add net user Turkish turkish /add net accounts /maxpwage:unlimited EXIT In $OEM$\$1\MUI I have a copy of everything at the top level of CD1 from the MUI DVD (I think the files from all 5 CDs are the same). I also have the directories for the languages I chose: IT.MUI, FI.MUI and TR.MUI: 05/02/2009 20:39 <DIR> . 05/02/2009 20:39 <DIR> .. 20/09/2001 12:00 3,661 EULA.TXT 05/02/2009 19:37 <DIR> FI.MUI 05/02/2009 19:36 <DIR> IT.MUI 20/09/2001 12:00 17,374 MUI.INF 20/09/2001 12:00 206,952 MUIQFE.EXE 20/09/2001 12:00 490 MUIQFE.INF 20/09/2001 12:00 84,992 MUISETUP.EXE 20/09/2001 12:00 17,023 MUISETUP.HLP 20/09/2001 12:00 14,560 README.TXT 20/09/2001 12:00 15,392 RELNOTES.TXT 05/02/2009 19:37 <DIR> TR.MUI 8 File(s) 360,444 bytes 5 Dir(s) 109,731,352,576 bytes free Right now the accounts get created, as expected, but the MUI install doesn't happen (although it does get copied to %systemdrive%). I've never used cmdlines.txt before, so maybe someone can point out what I'm doing wrong before I have to go and work it out for myself. Once that minor detail is sorted out, all that is left is to set each user to use the appropriate language. I can imagine that it is easy enough to achieve using AutoIt or similar but it should be possible to do it via the registry and maybe some file hackery. BTW: Each language pack is about 90MB, and the final .ISO was over 900MB. So, even allowing for 90MB of Italian stuff you don't want, that's still 800-850MB total size. If you expect to fit this on a CD you'll need to slim down the XP source using nLite. (Although given that DVD-Rs are so cheap, I'm not sure that this is worth the effort!) -- deadbug

@cdob Thanks for posting that - there's plenty to work through! But that's good, plenty of useful ideas. I've not really played much with hard links under XP so I've yet to work out what the gotchas might be. I do like the idea though of being able to create various flavours of DVD or CD on demand, so I'll have to look into that. As for DriverPacks, any reason for prefering \ABCD\OEM to \OEM? I've not really done much with DriverPacks yet other than integrating it into my MB DVD for XP Pro + Home. -- deadbug

Well I've just found that I don't know how to put a screen shot in here! I've attached the images instead, maybe that'll actually work! The DVD boots to an ISOLINUX splash screen (main.jpg). I hit return to boot the DVD (rather than timing out and booting HD1) and then I get to the screen in install.jpg. I can now select menus with the usual left/right/up/down arrow mechanism until I get to apps.jpg. Here I've got what I want and I hit return. Now it will fire up XP and I'll end up (after manually partitioning) with Windows XP SP3 + updates + apps. I don't have radio buttons yet, but if I did I'd compact thing somewhat and have a window with [sP0/SP1/SP2/SP3/SPextra] with exactly one selectable at a time and a separate radio button to choose DriverPacks or No DriverPacks. Just a small matter of programming. -- deadbug

This page tells you how to handle MUI: http://unattended.msfn.org/unattended.xp/view/web/82 I assume you extract once for Turkish and once for Finnish and do both in cmdlines.txt. The unattended guide already handles adding users: http://unattended.msfn.org/unattended.xp/view/web/27/ EDIT: Just noticed that MS have a page about this too: http://www.microsoft.com/globaldev/referen...nattended2.mspx

So if you were doing this manually, is this what you would do: -1 install windows XP pro english -2 upgrade to SP3 (if necessary) -3 apply MUI to add Finnish & Turkish -4 create user F, language = Finnish -5 create user T, language = Turkish -6 set flags. If that's close, then 1 & 2 is easy. I don't know how MUI would be applied normally so I cannot help with (3). 4 & 5 should be in the guide 6 Turns out to be trivial - having created the user, place the appropriate image in the "right place" in that user's tree ... I forget the right place but I can check tonight. -- deadbug

This sounds like a fairly straightforward multiboot DVD. Try the multiboot forum here. If you follow flyakite's tutorial, where he shows how to install (say) Windws XP SP1 and Windows 2000 SP4 (or whatever it is) you just do exactly the same except once you do Finnish windows XP and once you do Turkish Windows XP. The applications are also fairly straightforward. The unattended guide on this site walks you through various methods of unattended install. I use WPI (also has a forum here) but there are plenty of other methods. You can (I think) rip out all the bits you say you don't want by using nLite. I'm not clear what you mean by "install both XP SP3". I assume that you mean that each of the two installs should have SP3 as part of it. I'd suggest going further and having RyanVM's post-sp3 install slipstreamed into both. If you use CDIMAGE to prepare your ISO, then it will "notice" when certain files are identical and only write them once (but they end up in the TOC the right number of times). I have XP Home + Pro SP0,1,2,3,3+RyanVM, Windows 2000 SP0,1,2,3,4 all one one DVD along with ~1.5GB of apps and UBCD. So i think (unless office is now even more incredibly bloated than it used to be) you'll have no problem fitting all your stuff on. -- deadbug

See?, no hands, no bootsectors.... B) You can also rename SETUPLDR.BIN to whatever you prefer, etc., etc. OK. That saves me one file per boot foler, but I still need the boot folder. I'll have a play with GRUB4DOS (if there's an arrow-driven text-menu system with radio buttons, I'm sold :-) otherwise I'll have to finish this project before I take on that one!) So, am I building my boot folder properly ...? -- deadbug

Thanks! Why? I had a brief look at GRUB4DOS (after being slightly distracted by GNU GRUB!) and I don't see how it avoids bootsectors? It seems to chainload them so they'll still need to exist. The current AIO can (for example) boot Windows 2000 SP4 for a regular install, boot Windows 2000 SP4 for an unattended install, boot Windows 2000 SP4 for an unattended install and silently install a "few" apps. It can do the same for Windows XP Pro SP3. That's six boot sectors and six boot folders. I boot the DVD, start the boot menu, pick the OS, choose partitions and it does the rest, taking however long it takes. Short of not offering so many options (and actually I offer more ...) I don't see how I can cut down on the number of boot sectors and associated boot folders. In fact, having recently integrated DriverPacks, I now find that the initial text mode boot slows down (by a number of minutes) so I want to make that an option too. (I still want DriverPacks so that if I install on an unfamiliar machine it installs as much as possible, but on my machines I want a slimmed down version so I'm not waiting so long). That's part of the reason I started on this odyssey. If I put together a "build" tool that does what I want but takes out the bulk of the tedium, I can investigate speeding up the process while at the same time integrating the drivers I know I need (and perhaps decompressing them too). GRUB4DOS looks interesting, and I'm tempted to go and play with it and see if I can get an AIO DVD built that boots with it. But it looks like another tool that does pretty much the same job as ISOLINUX. The immediate plan is just to build a boot folder manually. I already have a working exemplar on my existing AIO-DVD, so I'll definitely know when I've managed to build an adequate one. I'd just like to know whether my approach is sound or whether it'll just be a fluke if I get there. It would also be nice to have some confidence that it will work correctly when Windows XP SP4 comes out :-) The XP USB stuff might help somewhat (I'll poke through it in the next few days - you never know when some seemingly irrelevant snippet will suddenly prove to be crucial) and I might even want to build an AIO-USB at some point (especially since 8GB ones are now cheap). But I expect that that's really an entirely new project, filled with its own kinds of fun! Well it's a good deal more powerful than a BAT file :-) Actually, I was initially going to use AutoIt for this too, but I know Ruby better so I thought it would be quicker to do this part in Ruby. I nearly went with wxRuby for the rest but (as it took too long for me to get "into" it) I now expect to do the rest of the heavy lifting (with or without a GUI) in AutoIt. If it turns out that AutoIt can't cut it, then I suppose I'll be looking to build a GUI using MS tools (always assuming the freebie Visual dev stuff can cut the mustard). -- deadbug

Until now I've used flyakite's method for creating my multi-boot DVD Flyakite's multiboot DVD. But I've seen several posts that suggest building the boot folder via some method other than running winnt32.exe. This one http://www.msfn.org/board/index.php?showtopic=58446 (which was pointed out to me in the PM that prompted this post) for example does it. But it seems to be a bare .exe file, and I'd prefer to know what is going on under the hood, so to speak. I've begun to put together a simple ruby script that parses DOTNET.INF and decides what to copy across and where to copy it to based on what it finds in any [FloppyFiles.*] and [RootBootFiles] sections that it sees. I was also parsing TXTSETUP.INF to determine whether these files are expected to be found compressed in I386 or not, but it seems simpler to just look for the compressed version first and then the uncompressed if the compressed one was not found. That leaves slightly modifying the copied TXTSETUP.SIF (the SetupSourcePath line needs to be rewritten) and patching SETUPLDR.BIN (it looks like XVI32 will do what I want from a script without human intervention). Finally, I should also produce a patched boot sector (e.g. PRO1.DAT in flyakite's tutorial iirc) but if XVI32 can patch SETUPLDR.BIN, patching a boot sector should be the same. So am I missing anything? Has anyone already done this (especially in an "open" way) and am I missing anything? (I guess I'll know in the next few days when I get some circular tuits ...). My overall aim (of which this is just one part) is to be able to download an updated RyanVM pack or IE7 pack or DriverPacks (or whatever) and have a simple GUI-driven process that can update my existing MB DVD with the downloaded updates. I can do it all now with just a few clicks, but I need to wait 30-40 minutes between clicks. I would prefer to just take what I did last time (in a .ini file), point it at the new component(s) and have it update the MB DVD in place. Again, if this is already done, please speak up now. (I expect to have to update it to account for my quirky AIO structure but that's OK as long as it's open enough for me to do that).

When I used DriverPacks, after the install DPsFnshr.exe was on C:\, which is what "%SystemDrive%\DPsFnshr.exe" would be. If I'd done it properly, then that finisher would have run (perhaps in GuiRunOnce) and then it would have cleaned up after itself. Now the testing involved in getting any reasonable number of Apps to install silently and correctly will dwarf what you've done so far. I generally find that by the time I've finished, filehippo.com's update checker has found a few Apps that have released new versions. It never ends :-)

I'm fiddling with a script to try and build a boot folder (per Flyakite) without having to do it the winnt32.exe way. I've noticed that if the diskid is of the for digit-then-underscore, then the specified file will be compressed, whereas if it has no underscore or the underscore precedes the digit, then the file will be uncompressed. So, for example, this line: ntkrnlmp.exe = 100,,,,,,2_,,3,3,,1,2 means that the source is I386\ntkrnlmp.ex_, whereas this line: ksecdd.sys = 100,,,,,,_5,4,0,0,,1,4 means that the source is I386\ksecdd.sys. I've noticed that most of the information floating around the net is either out of date or plain wrong (this topic being a notable exception!). The above applies to Windows XP Pro SP3. A quick glance at Windows 2000 Pro SP4 suggests that it has fewer options, but it looks like diskid is unchanged. One other point is that I think when the boot folder is setup by winnt32.exe, it uses DOSNET.INF to decide which files to copy and then uses TXTSETUP.SIF to decide which are compressed or not. (Unless one of the other TXTSETUP.SIF fields means "this is for the boot folder" ... actually newinstallcode2 might be a candidate for that, a quick check suggests that it is '1' for the few boot folder files I looked up). -- deadbug

The first thing to note is that DriverPacks must be the last thing you do - after nLite and all your manual hackery. So you can do everything else once and keep a copy of that safe, then run DriverPacks, build your ISO and test. If that didn't work, throw it away, restore your safe copy, and try again. Secondly, DriverPacks can (I think ...) be run manually using the settings from last time. If you are doing any manipulation with nLite or addon packs after you've applied DriverPacks then that could be your problem. So if you are building a single-OS CD your sequence should be something like: - prepare your directory with latest service pack (and txtsetup.sif and winnt.sif etc. for loading of apps and so on) - slipstream addons (like RyanVM, WMP, IE7) - apply finishing touches with nLite (if needed) - apply Driverpacks. If you are building a multiboot CD or DVD (e.g WinXP Pro & Home or Win XP and Win 2K etc.) then the basic sequence is similar except you invoke Driverpacks in a different way. Then, if you've followed flyakite's tutorial, you need to update the drivers in your \XXXX boot directory for each OS to which you've applied DriverPacks. Finally, if your D folder wasn't removed then either you've not run the Finisher (which is my current problem) or you've set some option in DriverPacks that asks it to leave drivers on the installed HDD (but I forgot what that option is - I don't think it's a default though).

I have a multiboot AIO-DVD (various forms of XP & W2K on there plus other stuff). Part of that DVD contains a fresh copy of SP3 (in a directory called SP3). I manually apply RyanVM's latest pack to create a new directory (SPR) and then slipstream some more bits into that. Then I copy that to SPD and apply driver packs to that. I also have aruby script that then goes and makes the (possibly) appropriate changes to the corresponding TXT-SETUP directory. So my SP3 directory was created once and will no longer need to be touched. My SPR will have to be manually updated every now and then. My SPD directory had to be recreated and have driverpacks applied while I was debugging the whole thing, but - once the driverpack ini files were created - this could all be done by a crude .BAT script. It costs a bit of space but it mean that as I was experimenting I could just run a batch script and come back an hour later and test in a VM. (Obviously I was doing all this experimenting as a background task ...). To speed up the testing I also moved everything that wasn't strictly necessary out of the DVD tree (so that CDIMAGE would produce a test ISO more quickly). I expect that you'll eventually get answers to some of your questions, but you may find it quicker to write a few scripts and do some testing while getting on with something else at the same time! -- deadbug

You say you have a problem with the date but you don't say _what_ the problem is ...

I use ISOLINUX now, so I'm pretty sure that if you have /boot/isolinux or /isolinux on the DVD, then it uses that. I used to use CDSHELL, if your DVD uses that then there should be a cdsh.bin somewhere. Once you know which of those two methods it uses, you can start to pick it apart (by looking at the corresponding menu files and seeing what they do for Vista). There are other ways of building a multiboot CD (easyBoot is one I think) but I've never used them so I've no idea where to look for those.

But if you can already do Vista+XP+Linux, you've more or less solved the original problem haven't you? Why don't you post how you did that and the original querent should have a good starting point for building their install disc. -- deadbug

If you use VirtualBox or VMWare player and test your ISO in that, you'll find it much quicker (and cheaper) than burning to CD/DVD each time. You'll probably be able to answer your own questions more quickly too! -- deadbug

That's fine - I was thanking not complaining ... honest

Thanks. I can report that it still works well with 4.2.0205.5730 but you must remember to leave a space before the /V"/qb" otherwise the installation will no longer be silent. (Thank heavens for virtual machines )

In this case I suspect that you've just not been sufficiently patient - you only asked earlier today. Having had unaswered questions before, I can assure you that you are not alone. It doesn't mean no-one cares, it probably means no-one knows the answer. In fact, in this case, I don't know the answer. I'm mostly replying to say that the idea of a CD/DVD that you just insert and it goes off and wipes a specific partition and starts an install is just a little scary. A while back someone I know wanted to read his Ee PC docs on his laptop. He popped in the CD, powered up the laptop and got in touch when he realised that he now had a laptop running Linux ... So do be careful about what you ask for ... -- deadbug

I upgraded from 6.something to 7.2.2 using the instructions here and it worked like a charm. It did mangle two things, but (given that I maintain config.js manually) that's pretty good. 1. It stripped all comments out 2. I define variables at the start and then use those rather than 'yes'/'no' so I can easily build a disk to install just new programs when I'm updating my disk. It would be neat if a future upgrade could preserve comments. It would be frighteningly good if it preserved all lines it didn't understand - in the right place :-) It took me two minutes to restore my manually maintained stuff, so anything that takes more than 10 mins to code isn't worth the hassle ! Once again, excellent job!

Effectively, yes. It has it's own subforum here (under member contributed projects).

Many thanks - worked perfectly for LanTool (and FlashGet too).