CoffeeFiend

I wouldn't be worried about the diazolidinyl urea. It's only a tiny amount (0.15%), and it's just a (fairly common) anti-microbial agent that's in pretty much every wet wipe out there (controlling bacterial growth in wet stuff kinda makes sense). My main concerns would be: -something soft enough i.e. cloth-based, not wood-fiber based -something that won't leave a ton of dust or lint behind -something that will be streak-free -something that has no harmful chemicals (such as ammonia) in elevated concentrations -a lot of glass cleaners will mess up the finish of the plastic (ammonia being a common cause), so bad idea there too Most of the time I just use a damp cloth. If it's really coated with a thick layer of grime then I also use some isopropyl alcohol. If you look again at the list of "ingredients" you listed: Polypropylene (39%) <- that's the "cloth" itself Water (60.5%) <- that's the other main component This accounts for 99.5%, the rest being things like preservative chemicals and such (sometimes fragrance too). You're really just buying fancy damp cloth here.

What they're talking about is, if you have 32 bit memory addresses, you can easily store that in a 32 bit register, which is rather logical indeed. Compare that to say, in the old PC XT days, with 20 bit memory addresses and 16 bit registers where we were stuck with segmented memory. That sucked, but 20 bit addressing gave us 1MB usable instead of a mere 64KB a 16 bit address would have limited us to (that would have been crippling) Now, it's a little more complicated than that. Modern processors have more than one operating modes (real, protected, virtual, etc) where addressing methods can change. And the Pentium 4 like you were referring to (actually, any CPU since the Pentium Pro) has more than 32 bit address pins. It actually has 36 of them, but you have to use PAE for that (still using 32 bit virtual addresses, but using page tables to map 4GB "windows" in that 64GB that's physically addressable). And 64 bit CPUs (x64) may have 64 bit registers, but don't have a 64 bit address bus as it would be pointless (and to some extent detrimental). They currently "only" have 48 address pins, limiting us to a mere 256TB address space.

That's creative wording by sales folks. Max continuous = 520W Max peak (for a short time i.e. until the overtemp protection kicks in) = 600W You wouldn't really want to use over 520W for any amount of time. Not that running your PSU at 100% of its capacity is a good idea either. That's very much like companies who sell audio amplifiers. We've all seen those before -- claims of 300W per channel, on a 8 channel amplifier, which you'd think would mean being able to deliver 2400W RMS total continuously to your speakers if that were true. But ~100% of the time (save for pro gear) that's creative math by sales people. It comes down to how much power a single channel could use (at the detriment of others), while using pretty much all the stored power inside all of the capacitors inside of the unit in a single microsecond (peak power) or something ridiculous like that. You just look at the power draw from the mains in the specs, and it says like 800W perhaps. Typical efficiency on those (push-pull setups) is 70%, so that could only deliver ~560W in total, across all channels, or 70W RMS/channel continuously (unless it somehow creates power out of thin air, by violating the very laws of physics). I've also seen a lot of computer speakers that claimed over 100W of power, while being fed by a 5W power brick... Sales people always get creative like that to make their products look good -- often much better than they really are... especially when it comes to PSUs. That isn't a bad unit you have, but a lot of generic power supplies way, WAY over-state their real capacity. This is why you see cheapo 650W units dying at 184W load When it comes to power supplies, quality REALLY matters.

Never seen that. First thing I would do is look at the installer's (installshield) log files and trace the install with Process Monitor as well.

I used to use Foxit reader years ago but I'm glad I dumped it. It was somewhat faster than the versions of Adobe Reader back then, but that was several ago. These days Acrobat Reader is FAR better at a lot of different things like printing, or features not requiring downloads to work (like that JPEG2000 plugin it always seems to be downloading) -- that's when foxit supports the format at all. It's completely useless for some stuff, for example any 3D PDFs generated with SolidWorks (can't see 3D PDFs, you only get a "Enable 3D View" error message) and other CAD apps (e.g. can't turn autocad layers on or off); I've had issues with color profiles in CMYK PDFs generated by Photoshop and other Adobe as well (colors were off). In a lot of "alternative" PDF readers, loads of useful features like file attachments, portfolios or digital signatures don't work at all. Plus, Foxit is slower at adopting new features (like PDF 1.8) so there's always the worry that something else won't work quite right. Foxit has distracting ads too (in the upper right hand corner), and it has tried pushing the ask toolbar as part of updates before, etc. If you stick to Adobe's tools, everything just works. BTW, Acrobat (not the reader) has great annotation tools. I use the object touchup tool quite a bit.

It does make sense. 408W is the combined power, and that's 34A indeed. That's how much you can use in total, adding up usage on all 3 rails. You also can't exceed 19A on any single rail (that's a limitation protecting against melting wires and such) This makes absolutely no difference as to how much power it can deliver to your various computer parts -- that's 520W max. It just guarantees that it has a decent efficiency which translates into savings on your power bill.

Have you looked at the error message? It clearly says it can't connect to the database. Did you actually enable mixed mode auth like it's asking for? Most likely, it requires you to setup the user beforehand as well (it has to have valid credentials & permissions to use the DB). Having installed the 64 bit version should make no difference whatsoever.

The main issue I see is if someone who has wscript as a default instead of cscript, the check you added will re-start it using cscript, but without the original cmd line args. You could change: wsh.Run "cscript.exe """ & wscript.scriptfullname & """" for wsh.Run "cscript.exe """ & wscript.scriptfullname & """" & " " & WScript.Arguments(0) but then that will fail if someone started the script without any parameters (and it wouldn't pass potential "extra" parameters either). So the ideal way around this is building another string, containing all cmd line args (if any), then passing those on, like such: Dim argsToPass, arg For Each arg In WScript.Arguments argsToPass = argsToPass & arg & " " Next If Len(argsToPass) > 1 Then argsToPass = Left(argsToPass, Len(argsToPass)-1) 'trim unecessary trailing space wsh.Run "cscript.exe """ & wscript.scriptfullname & """ " & argsToPass Otherwise there's no other issues with it.

To some extent it does, but too many at once just adds incredible overhead and easily brings any machine, running any OS, to its knees. Well, it's never been "official" indeed. But it's been common practice for a number of years for anyone who works in anything related to design in any sense to use font managers. I was using ATM Deluxe at the time (mainly with Corel Draw 7's fonts) on my Win95 box back then, but I recall ATM existing for Win 3.x before that. I'd say it's too much of a niche to introduce it as a feature in a mainstream OS. ~99.9% of the population have no use for it (so it doesn't make sense to make everyone incur the development cost), wouldn't understand any of it (complain about it being too complicated, useless, have problems with it, etc). Definitely not a big selling point for most people (I'd still love to see it built-in though) I don't recall anyone calling anything perfect in this thread But it's not "more broken" than previous versions of it (or other OS'es even) in any way, shape or form with regards to that. So I wouldn't expect a service pack (a bunch of bug fixes mainly) to include something so major. That's a way to see it. Nothing's perfect, nor is it ever going to be You have to create font sets once, yeah. That will dramatically speed up whatever OS they're using though (Win 7 or otherwise) and make it easier to find a particular font. It really sucks scrolling through a ridiculous number of fonts when 99% are simply irrelevant. With a font manager you only activate the categories that are of interest to what you're doing. It's not that much hassle to use really. And in some cases (like with InDesign and Illustrator), the font manager will automatically activate the fonts for them when needed. I've tried all the other font managers before, and IMO none comes close to suitcase fusion (v3 just came out 5 days ago seemingly -- soon with Photoshop support , I'll probably try it sometime soon)

There are no updates for a system that isn't broken? Colour me surprised. Obviously, you've chosen to completely ignore anything that was said in this thread, the history of this problem (Windows having behaved like that since pretty much forever), or the technical reasons that limit the number of fonts you'd want to use at once (it takes a lot of memory & CPU cycles to keep track of a ridiculously long list of fonts), and chose to blame Win 7 for it against all logic, and specifically the font management part of it, based on nothing at all. You've also chosen to ignore font management software that has existed for ages precisely for this. Except both have the exact same "problem" (Macs also use the same type of font management software, BTW), except they have far less software (especially Linux) thus making them not so suitable for "real work" in the first place, and Linux also has horrible typography. I have a bajillion fonts on this Win7 install, and it's working great (and really fast) -- thanks to Suitcase Fusion.

The same concept is in powershell. You can go through the registry exactly like you can navigate through a filesystem (cd/chdir, ls/dir, rm/rmdir, ... commands actually work too)

There's plenty of ways. The easiest would be to use a plain old MsgBox to display it first (btw, you can hit ctrl+c when a messagebox is displayed to copy all of its text). You'd replace something like wsh.Run "all kinds of stuff here" for something like Dim someVarName someVarName = "the exact same stuf you used to pass to wsh.Run goes here" MsgBox someVarName wsh.Run someVarName Although you can very easily debug vbscript compared to batch files. You can run yourscriptname arg1 arg2 arg3 ... argn //x i.e. you just add //x at the end of the usual command line. That will make it popup a dialog asking to select a suitable debugger (visual studio works great but there's a bunch of other options including the old script debugger). Then you can step through code, set breakpoints -- including conditional breakpoints (or with hit counts and such) which are invaluable, set watches, evaluate expressions, peek at some object's properties, change the execution path, view the call stack, etc. So there's usually ways to find the infos you need and debug stuff without having to use a lot of "messages" like that (be it MsgBox, WScript.Echo and similar ways). This stuff has been around for a decade

Because you missed the .ShowDialog() part slmgr.vbs takes forever to do this. Not much you can do about it. The VB app isn't really making any difference. If you don't like the functionality provided by slmgr.vbs, then it might be better not to use it.

The .NET Framework 3.5 is already included in Win7 (which is what I believe you wanted to activate). If you also want to activate Vista, then that still has the .NET Framework 3.0 included. On XP or earlier there's no version already installed, but it's not like you're going to activate that with slmgr.vbs either. Everything you've used will easily work using the plain old .NET Framework 2.0 or later. You can select which one you're targeting when you create a new project, but you can also do it for existing projects. For VB, go to the project menu, select YourProjectName's properties, then the compile tab, and the advanced compile options button at the bottom. The targeted version of the .NET framework is at the bottom there.

That's good news That's NOT how it works. This is where you get to take a beginner's OOP (object oriented programming) lesson. I knew this was coming next This will also become clear once you get the basics of OOP. Again, the problem is not understanding OOP. So here is the [really bad] OOP lesson for beginners (including the mandatory poor car analogy): Form1 and Form2 are what we call Classes. To make a poor analogy, you can think of a class as the concept of an object, like say, the concept of a nice car. You wouldn't use the said concept (a mere idea) to drive around, you have to use an actual object that exists, which means it had to be created at some point. An instance of the class was created, which is now what you'd call an object, which you can actually make use of. So if you followed so far, you understand you can't actually make use of Form1 or Form2 directly, being classes. You have to create an instance of them, and use those. When the program starts, VB automatically creates an instance of Form1 for you and then shows it (it's abstracted away to make it simpler for beginners -- in C# you would see your main Form being instantiated inside "program.cs" which loads first; in VB it's hidden from you). If you wanted to change something to this form's properties (like say, the background color), you would have to change the background color of the instance (the actual object, not the class). You use the "Me" keyword to refer to its current instance. And if you try to do "Form1.BackColor = Color.Black;" it will warn you too, telling you to use "Me" instead. "Me.BackColor = Color.Black;" will work as you'd expect. This is much like you wouldn't try to do a black paint job on the concept of that nice car, but on the car that was actually created. Hopefully you're still with me Now, if you want to show a 2nd form, you have to create an instance of it too e.g. "Dim someName As New Form2()". This creates an instance (creates an object you can use) which is called "someName", from the Class "Form2" (the concept, or "blueprint" of what you want to create -- "Form2" is only there to tell it what to make an instance of). Then you tell it to show that instance e.g. "someName.Show()". Mind you, that doesn't get rid of the instance of Form1. It's still there, it was not destroyed -- even if you asked it to hide it, it's still there. When you close that instance of Form2, the instance of Form1 is still running. So the code you written creates an instance of Form2 and shows it, merely hiding the current instance of Form1. Then once you close Form2, instead of Showing the already instantiated Form1, you're creating *another* instance of it, and showing that -- every time you close an instance of Form2, it creates a new instance of Form1 and shows that. That's a bit like using your car (Form1 being a car), and then once you have to move something heavy you use your truck (an instance of Form2), but once you're done with the truck, instead of going back to using your car, you get another one (a new instance of a car). Eventually you end up with a bunch of cars and a lot of debt (heavy resource usage, as many instances of Form1 are created and running at the same time). Most people can't afford using resources like this, and the logical thing to do is to just reuse the existing car. Similarly, the logical thing to do would be just showing the already existing instance of Form1. There's really easy way to do this too: In Form1's code, you write code that will create an instance of the Form2 class, hides the instance of Form1 as usual, and shows that instance of Form2. However, you want it to show that instance of Form1 again once you're done with that instance of Form2. The easiest thing to do is using ".ShowDialog()" instead of ".Show()". That will show the instance of Form2 and *wait* there. The following lines of code will only be executed once you close that instance of Form2 (just let it close for real -- DON'T create another instance of Form1). So it would be really easy to just add "Me.Show()" underneath that, thus showing that same Form1 instance again. So in Form1's code, you'd have: Dim someName As New Form2() Me.Hide() someName.ShowDialog() Me.Show() That solves your problem (no code necessary in Form2) There are several other ways though, like passing a reference of the instance of Form1 (reference to that object) to that Form2 instance (to its constructor), which would store it, and would call this object's .Show() method when closing, revealing it. In Form2's code, you'd store that reference to Form1's instance in a global variable, like this (right below "Public Class Form2"): "Private parentForm As Form". Then you'd declare your own constructor with the arguments you want -- like one to pass along that reference to Form1's instance: Public Sub New(ByVal refToForm1sInstance As Object) InitializeComponent() parentForm = refToForm1sInstance End Sub Now, when you create that instance of Form2, you have to pass that instance ("Me") to it, like such: Dim someName As New Form2(Me) Me.Hide() someName.Show() which will show that instance of Form2 and hide the instance of Form1. And to show that instance of Form1 again when the instance of Form2 closes, you'd do "parentForm.Show()" in the Form2_FormClosing event. This works too, but it's a wee bit more complicated. So it's probably simpler for you to just do Me.Hide(), form2InstanceNameHere.ShowDialog(), Me.Show() instead (works fine too, same end result). Hopefully that wasn't too hard to follow... I could make a better explanation but that would be fairly long. Use a label control. It's there exactly for this kind of stuff. When you have code that is susceptible of failing, you wrap it inside a try/catch block. In VB, you would do: Try Process.Start("filethatdoesntexist.exe") 'oops Catch ex As System.Exception 'do whatever you want with it here, like popup a simple error message: MessageBox.Show(ex.Message, "Oh Noes!", MessageBoxButtons.OK, MessageBoxIcon.Error) End Try That "Catch ex As System.Exception" will basically catch *any* type of exception as it's the most generic exception type. You can have more than one catch in there too, placing the more "specialized" types of exceptions first, finishing with the most general type. Trying Process.Start on a non-existing executable will actually generate a "System.ComponentModel.Win32Exception" exception type. More generic than that, you would have System.Runtime.InteropServices.ExternalException. More generic than that, you would have System.SystemException, and finally the most generic one is System.Exception. Using try/catch blocks is good practice. Handling errors is good, but it's even better to prevent them. You could easily check if the executable file exists when the form loads. If it doesn't exist, then you can disable the button or something like that. Or the code that is called when you click the button could verify if the executable exists first; if it's there simply run it (still using a try/catch block), otherwise give an error message. You do have to think about all these small things and come up with such solutions. Just like you wanted to validate the serial number before calling slmgr.vbs Hopefully that helps

That's only the case if your files are named like that on your hard drive, which most of the time wouldn't be the case (having copied from the CD). It definitely didn't do that the time I've tried it. Using -force-uppercase would make everything uppercase which is rather ugly. Again, it's Kelsenellenelvian's decision as it's his tool. If he wants -force-uppercase I'll be happy to add it.

Sinning is WAY too much fun, I ain't about to give it up Well, I figured it would help for those making multiboot CDs, but those people probably aren't the targeted type of user. It may still help a bit with some duplicate files in different folders (like say, installshield stuff, or others like InstMsiW.exe and what not...) I figured it probably doesn't hurt. Pfffft. I'd make one that goes to 11 if I could! I'll leave that choice to Kelsenellenelvian again. He should be able to change the 4 for a 3 himself in the script if he prefers that. I've also left "-m thumbs.db" as Kelsenellenelvian told me he didn't want any of them things (his previous script merely hid them, this should omit them instead). That's by far the easiest part cdob: Good points again (I'm not ignoring them). Like before, I'll leave it up to Kelsenellenelvian to make such decisions as it's his tool (I have no use for it whatsoever, and we're all running on Win 7 anyway) Finally, here's the code with the new mkisofs args: Option Explicit Const bootsect = "bootsect.bin" Dim fso, wsh, shl, fld, src, locpath, valid, bootable Set fso = CreateObject("Scripting.FileSystemObject") Set wsh = WScript.CreateObject("WScript.Shell") locpath=Left(WScript.ScriptFullName,(Len(WScript.ScriptFullName)-Len(Wscript.ScriptName))) If Not fso.FileExists(locpath & "mkisofs.exe") Then MsgBox "mkiofs.exe missing", 16, "Error" 'vbOKOnly=0 vbCritical=16 WScript.Quit(1) End If valid=false bootable=false If WScript.Arguments.Count = 1 Then src=WScript.Arguments(0) ValidateSourcePath() End If If Not valid Then Set shl=CreateObject("Shell.Application") While Not valid Set fld=shl.BrowseForFolder(0, "Select source",16,17) '16=BIF_EDITBOX; 17=ssfDRIVES If fld Is Nothing Then WScript.Quit(1) src=fld.Self.Path Set fld=Nothing ValidateSourcePath() Wend Set shl=Nothing End If If bootable And Not fso.FileExists(src & "\" & bootsect) Then If Not fso.FileExists(locpath & "\" & bootsect) Then MsgBox "Boot sector missing (" & bootsect & ")", 16, "Error" WScript.Quit(1) Else fso.CopyFile locpath & bootsect, src & "\" End If End If If bootable Then wsh.Run chr(34) & locpath & "\mkisofs.exe" & chr(34) & " -v -iso-level 4 -l -D -d -J -joliet-long -r -volid ""WinXP"" -A MKISOFS " & _ "-sysid ""Win32"" -b bootsect.bin -no-emul-boot -boot-load-size 4 -allow-multidot -hide bootsect.bin -hide boot.catalog " & _ "-duplicates-once -m thumbs.db -o " & chr(34) & src & ".iso" & chr(34) & " " & chr(34) & src & chr(34) Else wsh.Run chr(34) & locpath & "\mkisofs.exe" & chr(34) & " -v -iso-level 4 -l -D -d -J -joliet-long -r -volid ""Data Disc"" -A MKISOFS " & _ "-sysid ""Win32"" -allow-multidot -duplicates-once -m thumbs.db -o " & chr(34) & src & ".iso" & chr(34) & " " & chr(34) & src & chr(34) End If Sub ValidateSourcePath() If fso.FileExists(src) Then src=fso.GetParentFolderName(src) If Not fso.FolderExists(src) Then Exit Sub If fso.FolderExists(src & "\i386") Then valid=true bootable=true Else If MsgBox("The specified folder doesn't contain Windows XP" & chr(13) & chr(10) & "Create a data CD instead?", 36, "Warning") = 6 Then 'vbYesNo=4 vbQuestion=32 valid=true bootable=false End If End If End Sub I haven't tested the new options to see if the bootable CDs actually work at all (too lazy to fire up a VM)

Sounds like a mission for jaclaz aka MSFN SuperB

Yes, you would use a second form. I will let you try to figure out how to do this properly (a lot of people have a hard time with this at first) as I'm going to bed BTW, there are countless training videos and tons of great learning resources. Just have a look at this (start with Tier 1 and work your way up). There's also the guided tour. And the programming guide. And the "How Do I" video series on the VB Developer Center. And that is just the tip of the iceberg. There's TONS more out there (also tons of great books out there, tons of great community sites, etc). As usual, Google is your friend.

You mean, popup another window (form) with these on it? I'm not totally sure I followed. There's an edit button at the bottom of your posts As far as I know, this is included in all editions of both. This program doesn't need to run elevated but slmgr does. If you don't run slmgr.vbs elevated it will just popup an error message. There is a way to make sure you run elevated but it's not perfect... Look over here to see how you check if you're running elevated (you check using .IsInRole(WindowsBuiltInRole.Administrator) on WindowsPrincipal). Then if you determine you're not running elevated, you basically make your app run itself but in a special way (you create a ProcessStartInfo and set its verb to "runas", which will then popup the UAC window automatically).

That's not a bug, it's a feature (where have I heard this before?) That's in case you picked the wrong folder (wanting to select your XP CD) and mistakenly picked something else and don't want to burn that as a data disc, so it lets you select the folder again; clicking cancel will exit that.

That works just fine As far as I know the dashes are required, and it's case insensitive. Edit: As for the regular expression (to validate the format of the typed text), you will have to add "Imports System.Text.RegularExpressions" at the top where the other Imports is/are. A simple* regular expression to handle this would be: ^([A-Za-z0-9]{5}-){4}([A-Za-z0-9]{5})$ ^ <- matches the beginning of the text $ <- matches the end of the text [A-Z] would match any single character between A and Z but we've added more "allowed ranges": [A-Za-z0-9] will match any single character between A and Z *or* between a and z *or between 0 and 9 -- basically any digit of the serial {5} means it will have to be repeated 5 times so: [A-Za-z0-9]{5} will match a group of 5 characters, each being in the allowed ranges - <- matches the dash in the key, so: [A-Za-z0-9]{5}- matches a 5 allowed characters followed by a dash () are used to create a group, so ([A-Za-z0-9]{5}-) will match a group of 5 allowed characters followed by a dash ([A-Za-z0-9]{5}-){4} will match a set of 4 groups of 5 allowed characters each followed by a dash ([A-Za-z0-9]{5}-){4}([A-Za-z0-9]{5}) will match 4 groups of 5 chars with their dash and a 5th group of 5 chars (no dash) ^([A-Za-z0-9]{5}-){4}([A-Za-z0-9]{5})$ will match the same thing, but only if nothing else is typed before or after that. so the validator works like this: Regex.IsMatch(TextBox1.Text, "^([A-Za-z0-9]{5}-){4}([A-Za-z0-9]{5})$") This will return true if the text matches the regular expression i.e. if it's in the right format, otherwise it will return false. So you would use a If statement, that will run the slgmr command line if the Regex returns true (proper key), otherwise popup an error message using a MessageBox. The result would like this: Imports System.Diagnostics Imports System.Text.RegularExpressions Public Class Form1 Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click If Regex.IsMatch(TextBox1.Text, "^([A-Za-z0-9]{5}-){4}([A-Za-z0-9]{5})$") Then Process.Start("slmgr.vbs", "-ipk " & TextBox1.Text) Else MessageBox.Show("Key format is invalid", "Error", MessageBoxButtons.OK, MessageBoxIcon.Error) End If End Sub End Class I know that it might be quite a bit to grasp at once. Don't focus too much on the Regex but rather the logic and program flow instead (i.e. the if/then/else) * By simple I mean that it fails to account for some alphanumeric characters that aren't allowed in CD keys (there's only 24 allowed characters out of the 36 letters & numbers), not that it's ridiculously easy to understand the first time you get into it.

This part: isn't needed right now (although it doesn't do any harm just being there either). Try this (type something in the textbox like dir or ping 127.0.0.1 before clicking the button): Imports System.Diagnostics Public Class Form1 Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click Process.Start("cmd.exe", "/K " & TextBox1.Text) End Sub End Class

It's 100% yours to do absolutely anything you want (released under the DontCareTM license*), no credits necessary or anything. It's just a small script. Then again, I'd really double check the mkisofs options if I were you. * Not an actual license. Lawyers didn't care enough to write it.

Done: Option Explicit Const bootsect = "bootsect.bin" Dim fso, wsh, shl, fld, src, locpath, valid, bootable Set fso = CreateObject("Scripting.FileSystemObject") Set wsh = WScript.CreateObject("WScript.Shell") locpath=Left(WScript.ScriptFullName,(Len(WScript.ScriptFullName)-Len(Wscript.ScriptName))) If Not fso.FileExists(locpath & "mkisofs.exe") Then MsgBox "mkiofs.exe missing", 16, "Error" 'vbOKOnly=0 vbCritical=16 WScript.Quit(1) End If valid=false bootable=false If WScript.Arguments.Count = 1 Then src=WScript.Arguments(0) ValidateSourcePath() End If If Not valid Then Set shl=CreateObject("Shell.Application") While Not valid Set fld=shl.BrowseForFolder(0, "Select source",16,17) '16=BIF_EDITBOX; 17=ssfDRIVES If fld Is Nothing Then WScript.Quit(1) src=fld.Self.Path Set fld=Nothing ValidateSourcePath() Wend Set shl=Nothing End If If bootable And Not fso.FileExists(src & "\" & bootsect) Then If Not fso.FileExists(locpath & "\" & bootsect) Then MsgBox "Boot sector missing (" & bootsect & ")", 16, "Error" WScript.Quit(1) Else fso.CopyFile locpath & bootsect, src & "\" End If End If If bootable Then wsh.Run chr(34) & locpath & "\mkisofs.exe" & chr(34) & " -b " & chr(34) & bootsect & chr(34) & _ " -no-emul-boot -boot-load-seg 0x7C0 -boot-load-size 4 -hide " & _ chr(34) & bootsect & chr(34) & " -hide-joliet " & chr(34) & bootsect & chr(34) & _ " -hide boot.catalog -hide-joliet boot.catalog -relaxed-filenames -duplicates-once -iso-level 4 -J -l -joliet-long -allow-multidot " & _ "-sysid ""Win32"" -V ""WinXP"" -m thumbs.db -o " & chr(34) & src & ".iso" & chr(34) & " " & chr(34) & src & chr(34) Else wsh.Run chr(34) & locpath & "\mkisofs.exe" & chr(34) & " -relaxed-filenames -duplicates-once -iso-level 4 -J -l -joliet-long -allow-multidot " & _ "-sysid ""Win32"" -V ""Data Disc"" -m thumbs.db -o " & chr(34) & src & ".iso" & chr(34) & " " & chr(34) & src & chr(34) End If Sub ValidateSourcePath() If fso.FileExists(src) Then src=fso.GetParentFolderName(src) If Not fso.FolderExists(src) Then Exit Sub If fso.FolderExists(src & "\i386") Then valid=true bootable=true Else If MsgBox("The specified folder doesn't contain Windows XP" & chr(13) & chr(10) & "Create a data CD instead?", 36, "Warning") = 6 Then 'vbYesNo=4 vbQuestion=32 valid=true bootable=false End If End If End Sub