CoffeeFiend

Checking formatting is normally done using regular expressions. Otherwise you could check that the length of the typed text is just enough chars, then making sure that each character (one by one) is either alphanumeric or a dash depending on their position but that's not much easier... Once the app is working then yes, you should add that kind of validation. I'll help you with it too (it's more complex indeed).

It'll look in the current directory first, then on the system path. Just like if you ran the command from a command prompt.

Just like I said Inside it? Or in its parent folder? I mean, if the files are in c:\somewhere\XP (with i386 inside that), then you'd want the ISO to be c:\somewhere\XP.iso?

Running slmgr on a already activated PC with a valid serial number might not be a great idea indeed.

Right now, it gets created wherever you've put the vbscript. Like my previous post says, just let me know where you want it. I'll wait for a list of known working mkiofs parameters to update that Right now it runs either: "C:\whatever\path\to\mkisofs.exe" -b "bootsect.bin" -no-emul-boot -boot-load-seg 0x7C0 -boot-load-size 4 -hide "bootsect.bin" -hide-joliet "bootsect.bin" -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 "whatever.iso" "c:\here\be\dragons\XP" for a bootable XP CD, or for a data CD: "C:\whatever\path\to\mkisofs.exe" -relaxed-filenames -duplicates-once -iso-level 4 -J -l -joliet-long -allow-multidot -sysid "Win32" -V "Data Disc" -m thumbs.db -o "whatever.iso" "c:\somewhere\here\there\no\over\here\or\whatever" You can try to sort those from a command line perhaps. Find out what works.

No need, just run slmgr.vbs directly

Ok, just a quick change to see if it behaves like you want it to: 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) & fso.GetBaseName(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) & fso.GetBaseName(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 vbYes=6 valid=true bootable=false End If End If End Sub Again, I can't vouch for the specific mkisofs options, I'll let you test that stuff If you want to change anything else like where the ISO gets created just let me know.

You don't have to use any kind of declaration, just use the Process.Start method Try this: Imports System.Diagnostics Public Class Form1 Private Sub Button0_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button0.Click Process.Start("calc.exe") End Sub End Class Then perhaps: Imports System.Diagnostics Public Class Form1 Private Sub Button0_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button0.Click Process.Start("explorer.exe", "C:\Windows\System32") End Sub End Class See where this is heading?

How about when it sees it's not a XP CD (no i386 subdir), it warns you and asks if you'd like to create a data CD instead (messagebox with yes/no btns)? There really isn't a great way to make "menus" using VBScript (the console input methods suck pretty darn badly; for starters, there's nothing in vbscript quite like _getch in C++/ReadKey in C#/choice.com in batch or whatever you'd want to call that) so you'd be looking at using a completely different language instead...

"Imports System.Diagnostics" goes at the top most part (the absolute very first line) of the code. Then it'll work.

Is it really a XP CD you're browsing for? It tests to see if a i386 subfolder is in there. It could check for something else if you wanted, or blindly create it disregarding if it contains anything relevant.

That's about as easy as it gets, yeah. That's 3/4 of the simple GUI done, now I would add a textbox where you can type in the serial number too, without having extra forms or hiding stuff just yet. One thing at a time, then once that works start doing small changes one by one after. The code you pasted uses an InputBox though, not textboxes. Have a look again at this link. It shows you how it runs an executable (Internet Explorer) with and without arguments to it (an URL). Basically, you add "Imports System.Diagnostics" at the top then use "Process.Start" to do it. To use the text typed in a textbox, just use it's ".Text" property i.e. if it's called TextBox1 then use TextBox1.Text Now try to use that to pass it as an argument (perhaps to pass as an URL to IE), or you can try to run something else like the windows calculator (calc.exe) and such. Play with it until you got it figured out, then after that you can make it execute slmgr instead. You're getting there.

That would be an option. Anyhow. Here's a quick & dirty VBScript that creates a bootable XP ISO, taking the path as it's only argument (it asks for it if it's invalid or not provided). It should do the trick. The CD is bootable and the files are added (that much is tested) but you *may* have to tweak msisofs' options (haven't actually checked if the whole install runs fine). If that helps, here's the list of cmd line args for mkisofs. Again, very little testing has been done as far as that part is concerned (one VM boots to the CD and that's about it). Feel free to rename the bootsector to whatever you wish instead of bootsect.bin... Option Explicit Const bootsect = "bootsect.bin" Dim fso, wsh, shl, fld, src, locpath, valid 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 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 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 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) & fso.GetBaseName(src) & ".iso" & chr(34) & " " & chr(34) & src & chr(34) Sub ValidateSourcePath() If fso.FileExists(src) Then src=fso.GetParentFolderName(src) If Not fso.FolderExists(src & "\i386") Then Exit Sub valid = true End Sub Any changes you need, different language preferred, different mkisofs options, ... Whatever it is, just ask.

You can do that with a number of those frontends -- pretty much all those who are open source (like the one I linked to, which was the first hit using Google) Most of the space will be taken by mkisofs in most cases That can be done fairly easily... Anyhow. Writing such a script (or a HTA or whatever else) is really simple and quick. The main "hurdle" is knowing where you expect things like the bootsector to be stored (AFAIK you can't legally redistribute this either), and any particular tweaks/settings you'd like to use for mkisofs (if any).

That's pretty much part of the leftover 10% (that, and building a simple GUI). The HTML knowledge will help a little bit creating the GUI (you also need some CSS knowledge for that too if you want it to look any good), but that's about it (it's not just straight HTML, there's also the HTA "header" part). The code that will execute commands will be either VBScript or JScript. There is no way around knowing the basics either language, to either run the external apps or using DOM (yes, you also have to understand the basics of that) to get the content of a specific textbox using getElementById or a similar method. Actually, making a HTA version of this is a lot more complex than a C# or VB version (No need to know HTML markup and the HTA bits + CSS for styling + VBScript or JSCript to make it do something + also DOM to interact with the form -- you just need basic understanding of one simple language)

Why not just one one of the countless mkisofs frontends out there such as this one (open source, autoit; there's plenty of others too, and in pretty much any language you could ask for)? Isn't that what you're looking for (instead of stringing bits & pieces of 3 so-so scripts together)? Only if you want that particular app started when someone passes a drive name as an argument (it's meant to create ISOs from a disc in the said drive -- not that it even checks if it's a CD/DVD drive though)

Much like Kelsenellenelvian said. A few fonts don't normally slow down any version of Windows. But if you put a completely ridiculous amount (thousands) in it at the same time (tempting if you do graphic design of any kind), it will slow down to a crawl, no matter which version. It's been like that for as far as I can remember (Win95 at least, just the fonts from Corel Draw 7 made a high-end computer unusable). I can't think of any reason to blame this on built-in font manager either. That is exactly there are elaborate font management systems like Suitcase Fusion 2 from Extensis (which is great BTW), where you make font sets to activate and deactivate as you need them.

If you say you have no programming experience, I'd say pick something easy, either C# or VB 2010 (mainly depending if you prefer C-like or VB-like syntax better). C++ is more complicated to learn, and it requires the VC++ runtime to be installed, whereas C# and VB apps will work out of the box on Win 7. You can use slmgr to do this (activating & such), or you can use a number of underlying APIs to do this. Personally I make WMI calls to take care of it (very much like slmgr.vbs does itself) which should be fairly easy in either language, or even in VBScript/JScript. That's a LOT of fun in C++ though -- you have to call CoInitializeEx, then CoInitializeSecurity, then CoCreateInstance to get a IWbemLocator object, then its ConnectServer method, then CoSetProxyBlanket, then exec a query using its ExecQuery method so you can use an actual instance of the SoftwareLicensingService class (iterating through the collection), to then call GetObject on it, so you can get a pointer to its InstallProductKey method, for which you have to add a parameter (using a VARIANT type), to finally call its ExecMethod method -- plus all the necessary memory allocation/freeing (SysAllocString/malloc/...), error handing on every API call (checking the returned HRESULT, etc) and other fun stuff like that. Obviously, using WMI is a lot easier in C# or VB. Or you could make calls to the underlying APIs (that would me more "proper" in a way), but those basically are not documented, and not exactly what I'd call "easy to use" either (reverse engineer it to figure out the arguments, etc). Then again, you can just call slmgr too. Making a GUI app in C++ (i.e. a MFC app, although you could go C++/CLI instead) has a much steeper learning curve (i.e. working with the message loop vs WinForms or even WPF with C# or VB) As for using a batch program, it's really not a whole lot easier to do than VB or C# IMO, and you don't get a very fancy GUI there either, and you're quite limited in many ways. You can also integrate your very own "Keyfinder" in the app itself with C# or VB (no need for an external app for that). HTA is another option indeed. It's better if your HTML + CSS + either VBScript or JScript knowledge is already up to par (or you intend to run this on older OS'es w/o the .NET framework already built-in such as XP), otherwise there's not much reason to pick that over C# or VB. There's always AutoIt too... You'll have to make the language choice by yourself. I'm purposely not including a 100% pre-made app to do this (yes, you can call me a bast****) just so you can learn some stuff along the way. This is very much beginner's stuff (especially if you just call slmgr & an external key decoder) and you can definitely handle it. If you choose C# or VB you can grab Visual C# or VB Express which is more than adequate for the job. Then have a look at this page, which is the official documentation on how to start another process. Pick the method with the signature that suits you better -- probably "Start(String)" -- and check the sample code provided. That's 90% of the job right there (starting the 3 apps). All of this can be done in 3 lines of code total if you use slmgr.vbs and an external keyfinder app (it would have been FAR quicker to write it for you than writing this post). At least give it a shot You can do it!

Ok then. WMIC merely makes calls to WMI methods, so here's a quick and dirty vbscript that makes the same query and calls the exact same method: Option Explicit Dim oWMI, oSR, colItem, objItem Set oWMI = GetObject("winmgmts:{impersonationLevel=impersonate}!\\.\root\cimv2") Set oSR = GetObject("winmgmts:{impersonationLevel=impersonate}!root/default:SystemRestore") Set colItem = oWMI.ExecQuery("SELECT * FROM Win32_LogicalDisk WHERE DriveType=3") For Each objItem in colItem oSR.Disable(objItem.DeviceID & "\") Next Very little testing of any kind has been done (only 1 VM, with 1 drive, once) but it seems to work fine (even the restore points got deleted) Edit: the board seems to screw up the code formatting, especially with code tags (still messed up with quote tags or none at all). Watch for the parenthesis after cimv2... It should be on the same line, and if you see a space there, then it's the board that insists on adding it for no good reason. If you hit the "reply" button, you'll seemingly be able to copy/paste the code in its un-crippled format from there. Sorry about that, there's nothing I can do to make IPB work as you'd expect it to.

You can't (not that I would want to). That's a marketing photo made by an ad agency (Art Snob Solutions) for an online store (software-asli.com) for CS4. As in, an actual photo of that all stuff (boxes, paint, etc) laying there on a seamless background, laid out to resemble photoshop. It's not an actual Photoshop interface. Bigger version here. Pics of how they've done it here. Now if you could get PatchMath and reshuffling in there (as seen in the previews) I'd be beyond happy. Hopefully CS6 will have it... in 2 or 3 years.

Why even do it this way if you want to disable it for the entire machine? Why not use HKLM\SOFTWARE\Policies\Microsoft\Windows NT\SystemRestore\DisableConfig to disable it completely?

According to Google, it's stored under HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\ShellState

It totally depends on your actual needs. jaclaz has summed it up pretty good. What apps would you be running on that? Very few apps will keep 8 cores busy and need 16GB. If you need that kind of power for heavy number crunching or similar tasks (vmware, database server, etc), then the price might be OK. For a bit cheaper, you could pick up Intel's absolute most fastest CPU: a 6-core Intel Core i7-980X (beats the pair of Xeons on some tests, but then again it all depends on your actual work load), along with a half-decent X58 board which has 6 DIMM slots, and 12GB of DDR3. An if you're OK with "only" having 3/4 of that incredible amount of computing power you can find something that costs significantly less (e.g. Intel Core i7-875K, half-decent Socket 1156 mobo, 8GB of DDR3). And if your workload isn't quite that heavy after all, you can still build a great quad core system for pretty cheap. But then again: -hopefully you don't need much storage space as it will cost you -ditto for a decent video card if you need one, not that you'll really be able to find something very nice in low-profile and half-length anyway; and there is no "real" x16 slot, much less a 2.0 one; this only has a plain old, lousy VGA connector too (no DVI, no HDMI, no DisplayPort...) powered by a AST chip which I'm sure feels perfectly adequate to run Windows 3.1 -forget about USB 3, no firewire, very limited storage options, and very limited expandability ( -this has no audio outputs of any kind, whatsoever -yes, such 1U systems can be amazingly LOUD, and not so convenient for most office spaces -replacement parts, should you ever need any, will cost you a pretty penny. A replacement for those redundant hot-swap server PSUs? $245 each. A replacement for that non-"standard" DVD drive assembly? $330. Then the expensive FB-DIMMs, fancy fan modules, etc... Again, without knowing what you'll actually do with it, we can't say much.

It won't force you to install the latest SQL Server. Go under the "Web Platform" tab on the left, then under "Database" click "Customize". You'll see the necessary driver listed.

Tarun is right. Vista is still pretty secure but when you start going further you really lose a lot of security. For the record, I have yet to see a single Vista or Win 7 machine with a virus, ever. I wouldn't be so fast blame Windows either. There's just so many possibilities: infected installation media/image? end users with admin rights? careless admin? Someone carrying an infected executable (driver, app, installer, etc) on a USB memory stick to install it on there? not keeping patched? the list is endless. Also, AV's aren't 100% foolproof either, especially with really recent threats. Whatever got your win7 box infected (with up to date AV definitions), would have been infected your Vista and XP (x64 or not) boxes just as well.