jaclaz

It is possible, unfortunately I crypted the info about that method and cannot read it anymore. Seriously, you can try any of the BATCH compilers, depending on the complexity of your batch they may work or not, or you can try obfuscating the batch: http://www.ericphelps.com/batch/samples/obfuscating.txt jaclaz

See if these: http://www.msfn.org/board/merge-SWM-single-WIM-t89955.html http://www.msfn.org/board/Question-Asus-SW...es-t109293.html http://www.msfn.org/board/Vlite-HP-recover...sc-t105419.html http://www.msfn.org/board/Recovery-CD-t114830.html apply to your Recovery media. jaclaz

also, some programs from Uwe Sieber: http://www.uwe-sieber.de/drivetools_e.html (haven't tested them in 9x, but should work ) jaclaz

Change this: to this: Basically the same entry is written TWO times, one in the "default" tag, which means that it is the one that will be booted without user intervention and once below with a "description" (the part between quotes) that is what you see when you boot. BUT if ONLY one description is present, the user has no "alternatives" to choose among, so the only available choice is not even displayed, and no "timeout" is given, so you need adding (temporarily) another entry (the one in bold italic above) that by the way is an entry to boot the same system in a "diagnostic mode", useful in cas of problems. Once you have tested the feature, you can remove last line from the BOOT.INI or reduce to nearly 0 the "timeout" value. jaclaz

It could be almost anything from what you say. And yes, it is possible that it is a RAM problem. I would try running MEMTEST+: http://www.memtest.org/ jaclaz

Not yet had enough time to go through it, however, it seems to me that you forget the possibility of a SCSI drive and of a Removable SCSI drive. Get the the Perisoft minifile and miniram drivers and try it: http://www.perisoft.net/miniport/index.htm jaclaz

Post the contents of your boot.ini. jaclaz

http://www.ss64.com/nt/pushd.html http://www.ss64.com/nt/popd.html You change the current directory to the same one where the file you invoked is (%~dp0 means d=drive p=path 0=the first parameter, i.e. the running batch), then you execute the command, then you restore current directory to whatever it was previously. jaclaz

You want a self deleting batch? Mind you is RISKY business, however, you need a temp file: save this snippet in your \Mysoftware\uninstall directory, naming it selfdel.cmd or something like that ECHO del %~dpnx0>%~d0\delnow.cmd ECHO RD /S /Q %~dp0>>%~d0\delnow.cmd ECHO del %~d0\delnow.cmd>>%~d0\delnow.cmd %~d0\delnow.cmd (this will just remove the two batch files and the \uninstall\ subdirectory - just in case - but you can modify it with hardcoded paths to have it remove also the main \mysoftware one) Some more details and examples here: http://catch22.net/tuts/selfdel jaclaz

No prob. Yep , "good ol' rule of thumb" is intended just as "common sense advice", I do agree that newish, modern apps should be able to deal with anything, but the point is that current modern BATCH language (which is not DOS), which I love and use, still has problems dealing with "names-with-spaces" and with some special characters. No problem whatsoever with long filenames, though. So what I am "asking" or "suggesting" is just to avoid 14 special characters out of around 223 (255-32) among which you can choose, thus I am attempting to "limit your freedom" but only in a small percentage, after all, 6.28%, which leaves people "free" for 93.72%. But apart from this particular problem, that ilko promptly fixed, using those special characters is something that will likely "break" a lot of software, and definitely any script, so it is in my view not "wise" to use them, and particularly when running a "new" software for the first time. Cheers, jaclaz

You are welcome, always happy to hear a problem has been solved. Anout the option you get when you boot, it is in text mode (the BOOT.INI or is it in the graphical screen? If it's in BOOT.INI it is trivial to get rid of it: http://www.msfn.org/board/BOOTINI-hard-drive-t25365.html (you may need to set "show hidden and system files" and possibly remove the Read-Only attribute to see/edit it with Notepad) jaclaz

It's mostly a "state of mind". There are people that find that defragmenting VERY often is needed, other that think that defragmenting MUST be done, but not so often. Compare this: http://www.msfn.org/board/Defragment-Program-t85812.html http://www.msfn.org/board/Defragment-Progr....html&st=22 As I see it it depends on the use the hard disk is put to, which filesystem is used, and so on, one user might need on a weekly basis, another one on a monthly one, a few a daily (possibly overnight) one. I would say that when it is needed, defragging a drive is useful, overdoing it is not, point is finding a way of compromise, i.e. at which level of fragmentation the performance decreases up to the point where a defrag is needed and when it is not. "Blindly" defragging too often, say daily or twice a day, even when there is not a real need, may put additional stress to the mechanical parts of a hard disk. Lots of articles talk about "case studies" and "researches", but utterly fail to provide a link to them, see this for example: http://www.brighthub.com/computing/windows...icles/1702.aspx The only studies you can usually find around are made by the defrag utility makers, thus I wouldn't call them "independent": http://findarticles.com/p/articles/mi_pwwi/is_/ai_n25159836 http://www.scribd.com/doc/101131/Is-RealTi...eeded-in-Todays OT, but not much , another hard disk related MYTH is on the way of being debunked, the "wipe-with-several-passes" secure deletion myth: http://www.911cd.net/forums//index.php?showtopic=21783 thanks also to this nice initiative: http://hardware.slashdot.org/article.pl?sid=08/09/06/189248 http://16systems.com/zero/index.html jaclaz

Look here: http://www.multibooters.co.uk/ jaclaz

You burned it incorrectly. The .iso file is the "actual whole CD", it must be burned as image, NOT as a data disc. To simplify your life, copy the .iso somewhere to your hard disk, then run this app: http://www.imgburn.com/ Then follow this guide: http://forum.imgburn.com/index.php?showtopic=61 jaclaz

Good to know. However, the good ol' rule of thumb says to ALWAYS use 8.3 DOS compatible names (and Paths): http://www.ss64.com/nt/syntax-filenames.html and comma is one of the NO-NO's. jaclaz

If I get it right, you have a i910 which should behave (wrongly) like the 915 G. On the same page: http://www.geocities.com/bearwindows/vbe9x.htm#7 You may want to try running INFOVBE: http://www.geocities.com/bearwindows/vbe9x.htm#7 http://www.bearwindows.boot-land.net/infovbe.zip to make sure about the available resolutions, then try contacting bearwindows , he may have (or find) a solution . jaclaz

Short Answer: NO. Long Answer: NO, but it is possible, though only through a rather complex procedure, not entirely documented and prone to problems, some references: http://www.msfn.org/board/Change-Boot-Driv...ter-t90495.html http://www.petri.co.il/change_system_drive..._windows_xp.htm http://www.msfn.org/board/Force-windows-dr...te-t112610.html http://www.msfn.org/board/drive-letter-pro...-b-t112917.html jaclaz

Yes, I remember similar problems with other Virtual Network software, as soon as the Command windows is switched to full-screen you cannot do anything. My "quick and dirty" solution at the time was to use a font for the windows that made it (in windowed mode) as large as the full-screen mode (only "losing" a few pixels at the top for the window bar). I never tested it, but maybe this could work : http://josh.com/tiny/ jaclaz

You mean apart the one by bearwindows? http://www.msfn.org/board/Asus-Eee-PC-Wind...1.html&st=4 Didn't you already tried it? jaclaz

Another approach: http://www.steelsonic.com/steelrunas.htm http://www.robotronic.de/runasspcEn.html jaclaz

You might be interested to this: http://www.msfn.org/board/run-program-Service-t83272.html jaclaz

@Vially All suggestions are welcome, but the idea of this GUI was to have something SIMPLER than the already existing batches. You may want to re-read the first posts of this thread: http://www.msfn.org/board/install-USB-WinS...4.html&st=4 up to: http://www.msfn.org/board/install-USB-WinS....html&st=10 For the "Advanced" user's the way to go is undoubtedly the wimb's batches as they offer more choices and are much more "customizable". The GUI tool was an attempt to simplify life to the less "computer savy" people. I don't think that making two "complex" tools basically with the same "engine under the hood" but with different "look" is useful. jaclaz

Yep, the specific procedure is widely spread, but the actual wording of the snippet you posted undoubtedly come from the blog I mentioned, most probably it was "copied and pasted" on some other site/forum, removing the "brand" specific references, where you found it. jaclaz

Here: http://www.msfn.org/board/context-menu-questions-t58214.html jaclaz

dear mg.eggink google for: "Boot up the machine, have it boot off the USB drive, and watch how fast the installation completes." It is much appreciated that whenever ones cites something, credits to the Author is given. Besides being fair to the intellectual property of the Author, it is often useful, as usually people who publish such things post follow-ups, updates or other info related to the matter. jaclaz