jaclaz

The usual "corporate" approach is usually different. Typically a bunch of identical machines are bought, say a lot of 20 or more, the IT installs and configures one of them "properly", tests it, then images it and deploys the image to all the other identical ones. I personally count as: One, two, three, many If the number is within 3, manual installation three times is at the end of the day faster than *anything* scripted/custom, etc. If the number belongs to "many", then usually an "imaging/deploying" approach/solution is IMHO the best choice. jaclaz

Sure, there is no problem in running XP in FAT32, Vista is possible, Windows 7 seemingly no, and not really because of the hardlinks, symlinks and junctions (though of course the size grows), but because of the stupid WinSXS, and the senselessly long stupid filenames: http://reboot.pro/topic/19643-winsxs-hardlinked-files/?p=182961 (the good news being that a Windows 7 on NTFS can be shrinked by hardlinking more stuff): http://reboot.pro/topic/19643-winsxs-hardlinked-files/ jaclaz

Come on : http://www.student.tugraz.at/thomas.plank/index.html get the needed Cygwin1.dll that is a separate download: http://www.student.tugraz.at/thomas.plank/cygwin1.dll_1.7.28_.zip and if needed the Zusätzliche DLLs http://www.student.tugraz.at/thomas.plank/dlls.zip Probably it forces to uppercase in the ISO9660 "namespace", not in the Joliet one, I believe. jaclaz

Well, just for the record, the good DELL guys managed to alter permissions even BEFORE installing the XP : http://www.911cd.net/forums//index.php?showtopic=15138&st=29 they IMHO deserve the first prize . jaclaz

Iso level 3 - if I recall correctly - does not change in itself the "base" requirement of files needing to be uppercase. The joliet extension should provide support for longer filenames and for "mixed case". Iso level 4 does not really exist, it is a form of iso level 2 or 3 with some restrictions removed. The -allow-lowercase is a violation of ISO9660: http://cdrecord.berlios.de/private/man/cdrecord/mkisofs.8.html i.e. if the -allow-lowercase switch is NOT used, then any non-conforming filename (in iso-level up to 3) will be uppercased to conform to ISO9660. So, your cdrom.sy_ will become CDROM.SY_ (and txtsetup will find it), or if you had cdrom.sys it will become CDROM.SYS (and txtsetup will still find it). The downside is that the gfx-boot.gfx or GFX-BOOT.GFX may become GFX_BOOT.GFX. A "Windows XP install CD" (original) has ALL FILES CAPITAL and txtsetup wants to have them like that (at least for the files used in it, it is very possible that after txtsetup the files used in the GUI part of setup can be in *any* case, as they are accessed by the "standard" windows which is case insensitive). In a "pure" install Cd you simply don't use "-allow-lowercase" and everything is fine. Grub4dos is historically hardcoded to find a /menu.lst (or /boot/grub/menu.lst or /grub/menu.lst) and until recently you needed to (as explained early) change in the the embedded menu.lst the string "menu.lst" to "MENU.LST" (and grub to GRUB and boot to BOOT, if you used the subdirectories). Recently (but as said cannot really remember when) it was patched in such a way that the menu is found anyway, but cannot say if it accesses "generically" the file-system as CaSe InSeNsItIvE now, traditionally it needed (and used only) the Rockridge extension, which is case sensitive, recent version may access either the ISO9660 or the Joliet names. A PE 2.x (or later) has normally a "boot" subdirectory (where the boot.sdi is), though cannot say if making it "BOOT" will change anything, a Linux may need a given file in lowercase (or in uppercase or MiXed MoDe/whatever). Any of the other things that you added to your DVD (and that you won't talk about ) may have one requisite or the other, some mkisofs parameter that "fixes" one thing may "create an issue" with something else, this is the dificult part when making "multi" CD/DVD's. The traditional way for me has been that of using -iso-level 4 and adding a Rockridge extension, and NOT add the "-allow-lowercase" i.e. this set of commands : http://reboot.pro/topic/9696-oscdimg-and-grub4dos/page-2#entry84348 and that I believe correspond to your 4.2 attempt (but I have ALL FILES UPPERCASE in the source directory on hard disk from which I build, and the above post does contain a reference on why this is done - that is year 2004, ten years ago). If you insist on having the files on the hard disk in lowercase because n-lite or some other program tweak made them like that, and you don't want to change them, you will have to use a "lower" -iso-level than 4 and NOT use with -iso-level 2 or 3 the "-allow-lowercase", and find workarounds for the issues that this choice may cause. The example with GFX-BOOT.GFX vs. GFX_BOOT.GFX represents one of such issues that is easily fixable, it is to be seen what other "needs", such as the "Umlauts" may require in the mkisofs parameters. jaclaz

Well, TXTsetup expects an uppercase CDROM.SY_/CDROM.SYS, so if you are not going to uppercase it in the source, you cannot have -allow-lowercase in the mkisofs.exe (which may cause other issues, like the dash/underscore one). jaclaz

Between your test 4.7 and 4.8 you changed TWO things at the same time: Bugfix-Version 4.7: ISO-Level 3, Joliet, RockRidge, NO relaxed-filenames, allow-lowercase, Bugfix Version 4.8: ISO Level 3, Joliet, NO RockRidge, NO relaxed-filenames, NO allow-lowercase Windows setup (SETUPLDR.BIN, etc,) or more generally "windows" knows nothing about Rockridge, but the setup is sensible to uppercase/lowercase, i.e. if you try with RockRidge enabled but with NO allow-lowercase you should have the same result as 4.8, implying that there are one or more files involved in the setup that are *somehow* in lowercase (whilst they should be in uppercase). If you do (from windows command prompt) a (let's say that your CD/DVD drive - real or virtual - is drive letter E: ): DIR E:\ /s /b> C:\my47dir.txton the 4.7 test and: DIR E:\ /s /b>C:\my48dir.txtwith the 4.8 one you should be able to find the differences comparing the two files As a further test you could - to make sure - uppercase everything related to the Windows setup on hard disk before creating the .iso, as cdob just re-suggested and re-enable the allow-lowercase. jaclaz

Good , but there are n versions of 0.4.5c, by EXACT version I was meaning EXACT, like 0.4.5c-2014-01-17 (right now latest 0.4.5c) or 0.4.5c-2013-03-03 (right now "featured" 0.4.5c). One or the other version won't change the behaviour with "classic" commands (like color) but may behave differently regarding behaviour when loading (like finding /menu.lst vs. /MENU.LST and similar, cannot remember when that changed). jaclaz

Which exact version of grub4dos are you using? At the command prompt issue: help colorand check the symbolic names listed:http://diddy.boot-land.net/grub4dos/files/menu.htm#display "gray" is not a colour light-gray and dark-gray are.http://www.rmprepusb.com/tutorials/grub4dos#TOC-Grub4dos-color-values There may be a typo in the actual output of "help color": http://diddy.boot-land.net/grub4dos/files/commands.htm#color where "light-gray" is spelled (or spelt) as "light-grey". OT , shades of gray (or grey): http://reboot.pro/topic/15878-world-is-not-black-and-white/ jaclaz

Yep, that is a clear example of the dash/underscore issue. A file named gfx-boot.gfx would be normally "uppercased" to GFX-BOOT.GFX, and a file GFX-BOOT.GFX is ALREADY uppercased (as the dash is not in itself an alphabetic character subject to lower/upper case) but for *some* reasons in the process also the dash is uppercased to underscore and the result is the GFX_BOOT.GFX (that the gfxmenu command cannot possibly find). To be fair, more than two versions (actually seemingly all of them) were actually booting (to grub4dos), the issues showed after booting (txtsetup not running and/or grub4dos failing to load the gfxmenu). jaclaz

What is the gfxmenu line in your menu.lst? (in "Bugfix Version 4.8")? gfxmenu /GFX-BOOT.GFXor gfxmenu /Boot/GFX-BOOT.GFXgo to the grub4dos command line and issue the ls command, check if the file is seen as ALL CAPITALS, as all small letters or in any different way from the one in menu.lst. (or use find / and [TAB] autocompletion) Usually a line *like*: gfxmenu /GFX-BOOT.GFX || gfxmenu /gfx-boot.gfxis used when in doubt, this will attempt loading GFX-BOOT.GFX and IF this fails, attempt to load gfx-boot.gfx. BUT there is a generic issue with the dash or minus "-", as it is considered to be the "small letters" correspondent to the "CAPITAL" underscore "_", a good idea to avoid issues would be to rename the file without the dash, to GFXBOOT.GFX, then this will surely work: gfxmenu /GFXBOOT.GFX || gfxmenu /gfxboot.gfxno matter if the file is (or is made by mkisofs parameters) in upper or lower case. jaclaz

The thread posted by Trip explains it nicely (last post): http://en.community.dell.com/support-forums/laptop/f/3518/p/19495053/20316997.aspx The only non-matching part are the dates (October 2013 vs.February 2014) jaclaz

Naah, the good guys at Malware Bytes were affected by the "modern disease", and besides making the site looking as the usual demented kids playground (and seemingly removing the manual update method from the new 2.x ): https://forums.malwarebytes.org/index.php?showtopic=145331 https://forums.malwarebytes.org/index.php?showtopic=145331&p=811956 seemingly you can get an outdated update from here point FAQ - Section A - Item #4: https://forums.malwarebytes.org/index.php?showtopic=10138&page=1entry490977 http://data-cdn.mbamupdates.com/tools/mbam-rules.exe Another good product going along the stupidity path .... jaclaz

The "long" url, besides it's length, contains a number of "special" characters, namely the ampersand "&", that are likely to not play well. I mean, temporarily try a "fire.bat" as following: @ECHO OFFECHO "%1"PAUSEWhat happens? Can you wrap the parameter in double quotes before? Something *like*: and try with this "fire.bat": @ECHO OFFECHO %1PAUSEWhat happens? jaclaz

Not really-really. If you get it from the original download from the MalwareBytes server: http://downloads.malwarebytes.org/file/mbam then it is possible, otherwise it is more likely that it is a "wrapper ad-ware" or the like added by the file hosting site. I mean, IF the good guys at MalwareBytes actually did want to add a "forced toolbar", would they have it detected by their own program? In your thread here: http://discussions.virtualdr.com/showthread.php?265249-New-Malwarebytes-2-00-0-1000-found-Trojan&p=1461023 you already got all the answers you may need. jaclaz

Again, the grub4dos has been ALWAYS developed by a group of Chinese programmers, and it has been CONSTANTLY mantained. The original sites were: https://web.archive.org/web/20051124034926/http://grub4dos.jot.com/WikiHome https://web.archive.org/web/20131126183730/http://sarovar.org/projects/grub4dos/ and the program was supported on the Chinese forums United DOS and Sysoft . Initially, and for a few years until 2009 the lead developer was tinybit, then another couple of nice guys (bean123, Climbing, and possibly a few others that I cannot remember) took over it because of some personal problems tinybit had, then chenall (yet another nice Chinese guy) started proposing (initially in a separate branch) a number of interesting and useful new features. After 0.4.4-2009-10-16 which is to be considered the "stable" last version of the 0.4.4 series (and NO previous version of 0.4.4 series is suggested) there were for some time two branches, the "tinybit one" (more "conservative") and the "chenall one" (more "experimental"). The two branches were later re-merged together, and the official grub4dos main developer became chenall. tinybit, still provides, when he can, patches and snippets. In the course of this process, access to previous sites was lost and/or sites were closed, until finally the development (still by the same guys) went on on the code.google site: https://code.google.com/p/grub4dos-chenall/ There NEVER was a "noticeable" gap (years) in the mantaining/developing of the project, only a rather complex number of changes to the project site(s). Last version on Sourceforge is 0.4.4-2009-03-31, the one on gna.org is 0.4.4-2009-06-20, on the (now dead) page on nufans.net: https://web.archive.org/web/20100212013943/http://nufans.net/grub4dos there were: the "old" versions up to 0.4.4-2009-06-20the "last" 0.4.4 version 0.4.4-2009-10-16the "history" with all intermediate versions https://web.archive.org/web/20100802045111/http://nufans.net/grub4dos/historythe "tinybit" repoisitory with versions up to 0.4.4-2009-11-12 and the 0.4.5-2009-12-12 https://web.archive.org/web/20091213024431/http://nufans.net/grub4dos/tinybit/the "chenall" repository with versions 0.4.4-2009-11-10 and 0.4.5-2009-12-23 https://web.archive.org/web/20100209075651/http://nufans.net/grub4dos/chenall/Then the development was taken by chenall, and in the new grub4dos site, https://code.google.com/p/grub4dos-chenall/%C2'> there are versions starting from 0.4.4-2009-11-14 and 0.4.5-2009-12-20. Rest assured, both myself and Steve6375 were around at the time, and actually if you can have this info in English is mainly because we managed to have reboot.pro (was bootland) become the grub4dos English support board for the project and a number of members helped with the "western" side of grub4dos. Of course, if you are happy believing that the project died and wasn't maintained for several years and that it was "saved" much later, you are very welcome to do so , though it is not an accurate representation of events. jaclaz

Sure , and between 3/4 and 4/5 of posts reference Linux, NT and XP, besides 9x/Me (and even Vista and 7), the differences between them and even include notes about use of dsfok (under NT based systems), of dd (under BOTH Linux and NT based systems), and some more generic dd philosophy. You might appreciate how I did not post a link to something really off topic, such as antigravitory cats : D@mn! Look at what you made me do! Yes, it shouid be the same, though MDGx seemingly found only the 32 bit one. A good question (that we cannot ask here ) would be "Who is actually running the XP 64 bit version?" jaclaz

Not in this case. JFYI (already provided link): http://reboot.pro/topic/14-grub4dos/ http://reboot.pro/topic/14-grub4dos/?p=133739 Possibly to get something that is working better? jaclaz jaclaz

To be picky, a firewall should be between you and a (possible) fire and not stand right in the middle of your office, preventing you to get to (say) the restroom or your co-workers' desks. In other words, it should be a safety measure against perils coming from the outside, not an obstacle to everyday work. Maybe this round the good Comodo guys overdid it a little. (or their "smart" Default Deny Protection is not as smart as one would expect ) jaclaz

Well, you don't *need* to, but it would have been nice of you to provide this information . Let me assure you how that information is not at all important to me, basically because I already knew about it, most probably long before you learned about the existence of nlite or mkisofs (but thanks for providing it ). For the record, the version of mkisofs I use has even a "-duplicates-once" switch! Good. Then the thingy is maybe not actually "running fine" or maybe it is "running fine BUT with wrong characters displayed" . The basic question remains,why would you ask for suggestions/guidance and later do something different? By the same tokens you should use only the grub4dos version that you can find on the sourceforge or gna.org page. jaclaz

Big bump, I know , but I happened to find - while looking for *something else* - a Toshiba UDF driver for XP (both 32 bit and 64 bit): http://wp.xin.at/archives/829 which may possibly solve the issues that KB321640 : http://support.microsoft.com/kb/321640/en-us completely FAILS to solve. Rigorously UNLIKE tested (not the 32 bit, nor the 64 bit one), reference is just for info. jaclaz

Why don't you post (as opposed to a "dummy" example) the actual thing that you are trying and the actual error you are getting (stupid as it might be)? We are talking of the Windows 98 COMMAND.COM, right? It is likely that you are hitting into one of the various limits to either PATH length or command line length (typically 127 or 255 characters if I recall correctly). If it's a URL, maybe you can use a shortened url, like tinyurl or similar, since you mentioned firefox extension: https://addons.mozilla.org/it/firefox/addon/tinyurl-generator/ jaclaz

Well, in my day, when I got my first computer I had to solder its components http://www.zx81.de/english/zx80_e.htm .... and we liked it. (Kids today...) : http://tinyapps.org/blog/misc/200702250700_why_in_my_day.html Would anyone now have the guts for it? http://www.petervis.com/Electronics_Kits/Sinclair_ZX80_Kit/Sinclair_ZX80_Kit.html jaclaz

I don't want to somehow make you deviate from your original path , but nowadays I would rather use a USB stick, with a (updated/integrated/etc.) .iso and *any* number of "F6 floppy" images with the various SATA/RAID/whatever device drivers. There are a few possible options, using a .iso or not: http://www.msfn.org/board/forum/157-install-windows-from-usb/ jaclaz

Now I see, you were following submix8c's suggestion, which I pointed out as not being (IMHO) valid for this scope, here: http://www.msfn.org/board/topic/171350-textsetup-wont-accept-nlite-dvd/?p=1072315 as said everyone has his own ways , still, the simpler approach is to create a .iso and then burn the image EXACTLY along the IMGBURN tutorial I also linked to. I also gave you a link to this thread: which talks about recent (and suggested) mkisofs.exe versions. (just for the record, I personally use always the Mingw versions) There should be no need whatsoever for symlinks or hardlinks in any Windows XP install CD/DVD Did nlite create them? (or did you add them, and if yes, why?) The almost 4 Gb seem to me like a very, very large (and possibly complex) build, just in case I will re-point you to my suggestion: http://www.msfn.org/board/topic/171350-textsetup-wont-accept-nlite-dvd/page-2#entry1072315 of trying first with a smaller, simpler one. jaclaz