jaclaz

With all due respect to everyone and to their opinions , the choice of an OS should not be something like a religion or a political party. An OS is a tool. It is good if it serves you well for the purpose you are using it to. If this purpose is fun and CP/M (say) helps you reaching this purpose, than CP/M is a perfect tool for you. If this purpose is a given kind of work and the OS helps you get it done "better" or "faster" then it is the right tool. As said elsewhere in one of my carpenter's comparisons, I have a hammer that I like very much, and that over the years has proven to work, for it's intended purpose, very well, having allowed me to drive nails into wooden planks nicely and swiftly, it is well balanced, has a very good grip, and weights just what is needed to drive nails in a few hits, even on hard woods, without being too heavy. Would I use it instead of a Torx 5 screwdriver to untighten a screw on a HD PCB? Certainly not. I will surprise most of you by telling you that I still have a very, very old MACBOOK portable OS 7.1 on which I have a small program that from time to time I use to convert/clean text, as I was never able to find a suitable substitute in the PC world, and because I am very familiar with that particular program and I am more productive with it than with other tools. Do I go around saying that MAC OS 7.1 is years ahead then current OS's? No. Can I say that it was years ahead at the time (we are talking of DOS 5.00 and the first appeareance of Windows 3.1)? Yes. And Windows 9x/Me has no support for NTFS or for files larger than 4Gb...... I am joking please NOT yet another debate of the Fat32 vs. NTFS type, please. jaclaz

I simply cannot. The .vhd image you are using is INVALID. Cannot say whether this is because it is of the "dynamic" type or simply because it is corrupted. Clearly there is no valid partition table (and I suspect not a MBR at all) as first sector in the image. Try converting it to "static": http://vmtoolkit.com/files/folders/converters/entry87.aspx and try again. jaclaz

I see , thank you. Windows SIM or Windows System Image Manager, not SIM manager, which is this one: http://msdn.microsoft.com/en-us/library/ee498248.aspx The good MS guys have a quirk to give confusing names. Judging from this: http://www.windows-noob.com/forums/index.php?/topic/575-what-is-windows-sim-and-how-can-i-use-it/ It is not entirely unlike the old XP embedded thingy. jaclaz

The FIRST "rule" when experimenting in grub4dos is to NEVER use a pre-made menu.lst and ALWAYS use command line instead. Your first menu.lst entry example does not make any sense to me, it must have been taken by some source (that surely has a reason for that manipulation) you you don't specify. Your second one is plain enough. .vdi is a format used by Virtualbox and has nothing to do with Virtual PC that uses .vhd. A .vhd file can be of TWO main types: "static" "dynamic" A .vhd "static" file is nothing but a RAW (or dd-like) image of a hard disk with a single sector APPENDED to it, this kind of file is as big as the virtual hard disk it represents. A .vhd "dynamic" file is smaller than the virtual hard disk it represents, as it only maps the parts that are actually used. Static .vhd's are supported by grub4dos NOT because they are supported, but because they are functionally identical to RAW images (that are supported) for anything that grub4dos needs out of them. Dynamic .vhd's are NOT supported. Now, IF your images are "static" boot to grub4dos, press "c" to get to command line and try issuing these commands: map /deb.vhd (hd0) [ENTER] map --hook [ENTER] root (hd0,0) [ENTER] chainloader /ntldr [ENTER] boot [ENTER] After each command grub4dos may (or may not) provide some feedback. Post the EXACT feedback you get after each command. For the record, this is seemingly NOT connected to "Install Windows from USB", as a general rule, when you are looking for support for the tools posted here, you caom here, when you need support for (say) grub4dos, you go to the grub4dos (unofficial) support forum: http://reboot.pro/forum/66/ jaclaz

Well, you could also actually READ what I wrote. I was talking of the interface or if you prefer of the way the whatever (as an example a scripting engine) would interact with the user. You can call it any name you want, but still it will be a scripting engine of some kind, as long as you give to it some "fixed" instructions (contents of the plugin), a number of "varaible" instructions" (the settings) and after you press a button to "build". The plug-ins (actually the instructions i them), in PEbuilder as well as in winbuilder, are processed sequentially. If I get it right, you have not such a different idea from mine, combine all the separate plugins in a whole "fat" plugin, to be later run "monolitically". Whether this is called a scripting engine or "mickey mouse" is not at all relevant IMHO. So, the idea (mine at least) is to run a pre-processor of some kind capable to resolve dependencies and duplicates BEFORE actually starting DISM or movingextracting/copying files and to assemble a monolithic "set of instructions" for the build. @Kullenen Ask May I ask what is "Embedded SIM manager"? Does it have another name? The one I found some reference about is part of 7 Compact to manage SIM's (cellular phone thingies). jaclaz

Have you tried a simple PSinfo: http://technet.microsoft.com/en-us/sysinternals/bb897550.aspx looking for "install date"? jaclaz

Don't want to seem too "captain obvious", but till now you have described the interface of *any* installer, including that of .msi files or common NSIS ones. In this respect NSIS could be a very good "scripting engine". That's perfectly fine and presents not much of a problem. That is one of the problems, the other being, still, HOW to manage the "interconnectedness of all things". But is the theme making a rounder wheel or on inventing a new kind of wheel (which incidentally runs smoother)? Yes, but these would be improvement to the same "paradigm", I had the impression that Kullenen_Ask was pursuing a "new" one. I will add to my previous notes that - no matter how the actual plugin is built or the code executed of whatever - the thing that I find extremely frustrating and "wrong" is EXACTLY the current paradigm. The current one (pebuilder) is: tick (or untick) a number of checkboxes/radioboxes (possibly add some other settings) build if failed try to rebuild changing the checkboxes/radioboxes you set or unset previously and (winbuilder) navigate/expand a tree tick (or untick) a number of checkboxes/radioboxes (possibly add some other settings) build (this consists mainly in watching senseless information across your screen and a blue progress bar) if failed try to rebuild changing the checkboxes/radioboxes you set or unset previously This is not in any way different from the "installer paradigm", with the difference that the "installer" has a small, finite number of possibilities, is by far "narrower" in scope and it is (normally) duly tested in the few possible configurations. We all know how many BartPE plugins or winbuilder .scripts are written by people that though good willing have often no idea (or a very little one) on how respectively a plugin or a .script should be written and how it should be tested. Since the actual engine has no (or very few) provisions for error checking BEFORE build time, the result is the current "click/build/fail/click somethnig else/build fail/loop" situation. As you might remember I tried to point out this problem since the very early times of winbuilder, but the paradigm has not changed and was on the other hand aggravated by the known syntax changes problems. jaclaz

Remember to notify Wikipedia that they should update their page: http://en.wikipedia.org/wiki/Shareware and promote your note from "Criticism" (where it is already) to "main content". jaclaz

AFAIK MS does not support in *any* way OEM software (such as the Toshiba installed OS surely is), entirely delegating this "burden" to the OEM, Toshiba in this case. jaclaz

Well, no. IMHO most of the problems with existing builders is that they started (mostly) without a "plan" and were adapted/changed n times (or were NOT changed where needed), and this exactly because there was not a "model" of the elements and not much thinking of how to put elements together BEFORE actually starting putting them together. jaclaz

Ok. Than, before demand fuel, first of all invent a good engine. I would gladly, if I could. If a batch (no GUI) is OK for you or if you can live with the graphical limitations of a pseudoGUI such as WizApp: http://wizapp.sourceforge.net/ I could be game. If what you will provide is: It can be done in batch allright, it might not be the fastest build engine in the world, but it will work allright, and once the format for the 4 elements above has been established, we may find someone willing to write a "proper" program using the same "fuel". How will be the ""dependencies" (I mean cross dependencies) managed? (this is the issue around which I am revolving, creating an effecitve way of represent such dependencies in a database or something like that) jaclaz

This is what my half@§§ed batches did (obviously without a GUI, let alone a "nice" one). as allanf pointed out, to me the real problem is the "fuel", NOT the "engine". jaclaz

But windows backup will make "normal" .vhd files and NOT .wim ones, AFAIK. Question is seemingly about .wim images jaclaz

Yes, this is an issue, that I have also being talking about since years, but as I see it is "independant" from the actual builder. Yes, but I don't really see problems in the actual tool (one may be sllightly better than another, but not that much) rather I see a lot of "missing" knowledge or settings or the way the available knowledge is scattered around. As you might know I once put together in a weekend a (very limited and as always half-@§§ed) builder in batch for a very small project, the issue as I see it is not the actual builder but "all the rest". jaclaz

The interesting part would if you create junction points (symbolic links) to the stuff on the "other volume" inside the "main volume". What would happen? jaclaz

Not being a programmer, I cannot be of help, even if I wanted to. But I would like to understand what are these "builder requirements" or, if you prefer, before reinventing the wheel, in which way wheel 2.0 should be made "rounder"? jaclaz

Wait a minute, from what I remember in 9x there is winipcfg: http://support.microsoft.com/kb/141698/en-us and there is NO IPCONFIG in 9x: http://support.microsoft.com/kb/183858/en-us jaclaz

Not only he doesn't understand, he also starts shouting! OBVIOUSLY, since it is potentially VERY dangerous code, I added a basic safeguard to avoid that some demented users would copy and paste it "as is" in the WRONG place (and delete everything in the subtree by mistake. The idea was to NOT allow someone that cannot even read two lines of batch to potentially make damages. Since OP asked help in writing a batch file and posted a non-working code that not only doesn't work but is is also evidently NOT following very basic batch or command line syntax, I assumed he was not at all familiar and thought that a safeguard would have been needed. jaclaz

Good to know Just in order to disambiguate 28 characters plus the square brackets, right? Like: [ABCDEFGHIJKLMNOPQRSTUVWXYZ12] being valid and [ABCDEFGHIJKLMNOPQRSTUVWXYZ123] being not. jaclaz

We must remember making an entry for this in the synonyms dictionary jaclaz

NO. This thread is ONLY (as in ONLY) for 7200.11. As CLEARLY stated n times in the thread AND in the READ-ME-FIRST (point #1): Please start a new thread about 7200.12 solution you found. This could be very useful, but a post or two inside this UNrelated "megathread" will get NOT the visibility it may deserve. jaclaz

Sure , it's actually "normal". The FILENAME (including path and surrounded by quotes if needed) of what you "drop" on a CMD file is actually parameter %1. Create this and save it as DROPONME.CMD: @ECHO OFF ECHO %1 PAUSE Drag and drop on it *any* file. jaclaz

I would like to point out how 3 or 4, as in : Music Video Backup etc are called here "a few" or "a handful" (and not as "many" or "lots"). As allways happens it is a matter of common sense and actually "intended use", besides "personal habits". And it depends on what type of backup solution you use. Defragging one "big" partition or "a few" smaller ones will take more or less the same time. Running chkdsk will make a difference (assuming that you run frist chkdsk and only if there are problems you run chkdsk /f or chkdsk /r). In case of filesystem corruption, only one filesystem will normally be corrupted (and not the whole "big" partition), and this may also help for recovery or restore chores. But you are both right, everyone has his own ways. jaclaz

If I may, using for the rest of the space a Partition ID WIndows 9x/Me does not know anything about, like NTFS or EXT2/3/4 should give the same result but if needed you have some storage space accessible by other OS's. jaclaz

I'll use it for you : WHAT (the HECK) is shiva? jaclaz