jaclaz

Yep, sure, but what was the actual question? Even Google calculator knows the answer: http://www.google.com/search?q=the+answer+...+and+everything jaclaz

There is no way to know the lifetime of a battery, different types of battery have different behaviours, a Ni-cd one has an expectancy of 250 to 500 charging cycles, but has a "heavy" memory effect, more recent Ni-Mh and Li-Ion batteries have reduced this to a minimum, and the number of cycles has increased to 400 to 800, but still some small "tricks" can be applied, though there is no actual prove i.e. "scientifical" comparison tests, even because two batteries from the same manufacturer can behave differently. Some links to read: http://hardwarehell.com/battery.htm http://www.batterycanada.com/Battery_Facts.htm More technical: http://www.batteryuniversity.com/index.htm http://www.batteryuniversity.com/parttwo-33.htm http://www.batteryuniversity.com/parttwo-34.htm jaclaz P.S.: DIY jobs can be done, though NOT recommended, unless you have good skills: http://www.electronics-lab.com/articles/Li...ruct/index.html expecially with Li-Ion batteries, it can be DANGEROUS

Basically some settings in the Registry must be changed. You can shave off some reboot time by NOT rebooting but rather terminating the shell (exiting to MS-DOS) and restart it with the command line WIN command. Moreover, most of the time you don't really need to re-start/re-boot for each install, you can install a number of things and unless one depends on another one a single re-start/re-boot will be enough to update all chnges in one round. Of course on some install this will not work beacuse in some instances a "real" re-boot is needed. The install programs can rely on various ways to complete install: 1) Autoexec.bat (in this case a re-boot is mandatory) 2) Wininit.ini 3) Winstart.bat 4) Registry keys, in HKLM or HKCU, typically: 4.1) Runonce 4.2) RunServices 4.3) Runex 5) The StartUp group, or All User Startup More details here: http://users.iafrica.com/c/cq/cquirke/startup.htm

See if this works: http://www.novell.com/coolsolutions/tools/16306.html jaclaz P.S.: IF it does, you owe me a beer

Back to the "NTFS on flash is BAD" topic, here is an interesting article in which wear-leveling algorithms are explained : http://www.mil-embedded.com/articles/authors/spanjer/ and an "official" article: http://technet2.microsoft.com/WindowsServe...3.mspx?mfr=true Imation: http://www.imation.com/didyouknow/technolo...ke_it_with.html Puts the Write cycles at "between 10,000 and 100,000" which is not really an "exact figure". See also this: http://ask-leo.com/can_a_usb_thumbdrive_wear_out.html As said, it is possible in certain conditions and with certain media to burn the flash memory in a matter of days or weeks, so you should know what you are doing before doing it. jaclaz

You should make a search for "computer lounge chair" on Google, a few examples: http://www.gizmag.com/go/1136/ http://www.gadgetreview.com/2005/12/super-...unge-chair.html http://www.nethrone.com/ http://www.kalkwijk.com/ximage/pid/144/i/26 You should be able, by searching in the various "gizmo" sites, for "chair", more examples and some accessories: http://www.gizmag.com/go/5947/ Cannot say about the prices, though, this one appears nice: http://www.productwiki.com/homedics_antigr...cliner_ag_2101/ jaclaz

I don't get it, do you expect to find something written by the good Microsoft guys (who invented NTFS as a better filesystem than FAT16/32) saying that NTFS is worse? Maybe there is, but you can go and search for it yourself, just remember that those guys are the same ones that said: 1) That Internet Explorer is part of Windows and CANNOT be taken off. http://en.wikipedia.org/wiki/United_States_v._Microsoft 2) That XP was NOT bootable from a USB Mass Storage device. http://www.microsoft.com/whdc/device/storage/usb-boot.mspx and some "users" proved them wrong: 1) After all IE CAN be taken off... http://www.litepc.com/ http://www.vorck.com/remove-ie.html http://www.nliteos.com/ 2) And XP CAN boot from USB.... http://www.911cd.net/forums//index.php?showtopic=14181 So, maybe, the problem with information is not WHERE it comes from, but rather IF it is accurate, an the only real judge is the single user for it's specific purposes. jaclaz

However, it is quite easy to see what is which.... [bEGIN SARCASM] Open up your home stereo loudspeaker, it should consist of two or three speakers. Identify the woofer (the biggest one). Now, try sticking your drive to the back of the woofer. If it stays attached, it is a magnetic disk, and you will have probably lost all your data, besides the mess you have made with the loudspeaker. If it does not, it is a Flash based one. [END SARCASM] Maybe you will be interested in these: http://deadline.3x.ro/adsense/ntfs_vs_fat32.html http://www.comp.ro/QWFAT32_NTFS.htm http://www.spcug.org/reviews/bl0401.htm There is no "good" or "bad", as much as there is no "one-size-fits-all" solution. On certain setups and for certain scopes, FAT is better than NTFS, on some other ones, NTFS is better. It's up to the user choose which one to use. jaclaz

Hmmm, it shouldn't be difficult: [bEGIN SARCASM] Just use this batch file: @ECHO OFF ECHO ECHO Pull off the PC mains plug NOW! PAUSE CLS ECHO If you see this message, it means that: ECHO 1) You (wisely) did not do what you were told. ECHO 2) This computer is a desktop and it is connected to an UPS. ECHO 3) This computer is a laptop and has a working battery. ECHO Please consider the above three alternatives and judge yourself which one is the ECHO MOST probable one. [/END SARCASM] Now, seriously, you can check for the laptop PCMCIA, as already suggested, here is some code: http://techsupt.winbatch.com/webcgi/webbat...ct~a~Laptop.txt jaclaz

I think you are getting this wrong, nlite should be run with "standard" XP CD, it is possible that your particular CD is not a "standard" OEM one, but rather a "modified" OEM one. Knowing make / model of your laptop might help, however you should look here: http://www.msfn.org/board/index.php?showtopic=75761 It is possible that your disc is not really an XP install disc, but rather a "Recovery CD", in that case you need to rebuild a CD, in this thread on the 911CD forum there are some related useful links: http://www.911cd.net/forums//index.php?showtopic=16381 jaclaz

@Tarun I second LLXX on this. Formatting and using a USB stick as NTFS will DEFINITELY shorten it's lifetime. Though manufacturer's are not saying it too loud , flash memory has a FINITE number of write cycles, at the moment that is estimated around 100,000 cycles. This means that the drive will normally last "forever" in normal use, but NTFS is a semi-journaled filesystem that EVERY TIME it reads a file actually WRITES something to the disk (access date and time, etc.). Though most (but not all) controller chip manufacturers do adopt a technique called "wear-leveling" that in simple words is a method to re-map the drive so that on average all sectors are written the same number of time, the number of write cycles in a NTFS filesystem is so high that a stick can be "burned" in a matter of days or weeks of intensive use. This has already happened, check the "winodws booting from XP" thread on the 911CD board: http://www.911cd.net/forums//index.php?showtopic=14181 http://www.911cd.net/forums//index.php?sho...5533;entry97519 The ONLY "safe" way to use NTFS on ANY flash based device under XP is to use EWF, a component from Windows Embedded that limits to the minimum the number of write cycles. There is a nice EWF tutorial by Sfiorito, who is also a member of MSFN, here: http://osf1.gmu.edu/~sfiorito/eXPinstall.htm Additionally, you may want to disable timestamping, though this is a Registry Tweak that applies to ALL NTFS volumes, not only to the stick. Of course, as long as it "YOUR" stick, you are perfectly free to "fry" it in the shortest time you can, but to actually suggest formatting a USB stick as NTFS, without a BIG WARNING about the side effect on it's lifetime is IMHO at least inappropriate. jaclaz P.S.: NTFS is undoubtedly a BETTER and SAFER filesystem, but, as said, not necessarily faster, see this comparison table: http://www.ntfs.com/ntfs_vs_fat.htm

Short answer: NO Long Answer: NO, but this has nothing to do with Windows 9x, is a "feature" of DOS: On the SAME drive that was booted MUST reside: IO.SYS MSDOS.SYS Autoexec.bat Config.sys and, normally, COMMAND.COM (but this can be changed through a setting in Autoexec.bat): http://goforit.unk.edu/msdos/msdos09.htm The same reason why you cannot rename "Autoexec.bat" to, say, "myauto.bat", those filenaes are encoded in the DOS files, and they must be on THAT same partition. Nothing prevents you however to make a c:\autoexec.bat like this: CALL D:\Autoexec.bat Moreover, though I cannot say if it useful in your "context" Windows 98 can be installed "completely" to a Logical Volume inside extended partition: http://www.allensmith.net/OS/XOSL/II.htm#II1 of course you will need a boot manager to hide partitions preceding the one on which you installed Windows 98, or those ones need to be with a filesystem that Win98 won't recognize, but the drive booted will remain "C:". Another interesting approach could be the one hinted here, though I never tested it for this particular purpose: http://www.geocities.com/freedatarecovery/ http://www.v72735.f2s.com/LetAssig/index.html but again, since the Letter Assigner has to be invoked from Autoexec.bat, you will however need to have it on the initial boot "C:" drive. jaclaz P.S.: to check version of a .dll/.exe/.ocx, check this also: http://lbrisar.htmlplanet.com/e_cmd32.html#top

You should be able to do that by modifying WINNT.SIF, see this: http://www.msfn.org/board/index.php?showtopic=84617&hl= jaclaz

You simply install NT/2K/XP/2003 in the Logical Volume inside the extended partition, the arcpath in boot.ini will already be correct, otherwise you can easily fix it manually, read here: http://www.msfn.org/board/index.php?showtopic=43610 http://www.msfn.org/board/index.php?showtopic=68193 http://www.msfn.org/board/index.php?showtopic=33030 and given links. But you can always boot the system with a boot floppy and fix the MBR from within the booted windows install. One of the posts above referenced has a link on how to make a boot floppy to start a NT/2K/XP/2003 system with corrupted boo.ini/NTLDR/NTDETECT.COM. There are several programs, freeware, for DOS and for Win32, the one I use is DSFI/DSFO part of the DSFOK package: http://members.ozemail.com.au/~nulifetv/freezip/freeware/ that has the options to do more than just the MBR, but MBRFIX, see links on my page: http://home.graffiti.net/jaclaz:graffiti.net/ or Roger Layton's MBRWizard will do as well: http://mbrwizard.tripod.com/ About Primary partitions, YES, you just set it as Active (checking that there is no other Active partition), i.e. you write hex value 80 in the proper location of the partition table, this can be done with any hex editor or with specialized programs. The one I use under Win32 is Beeblebrox: http://students.cs.byu.edu/~codyb/ About Logical Volumes inside Extended partition, THE "EXTENDED" PARTITION IS NOT A PARTITION, it is a "CONTAINER" for one or more Logical Volumes, see this: http://www.ranish.com/part/primer.htm The short answer is NO, but the long one is YES, but you need to manually arrange some parameters with a Hex editor, read this: http://www.goodells.net/multiboot/ or use a Grub4Dos: http://www.911cd.net/forums//index.php?sho...c=17144&hl= (search on 911cd board for "Grub4dos", you will find many useful hints and tips) jaclaz

Please note that, PROVIDED you are willing to have a SMALL FAT16 partition you can have: 1) DOS 6.22 installed in that Primary partition 2) Windows 95/98/ME installed in a logical volume inside extended partition (YES, it can be done, it's a bit tricky, but it can be done) 3) ANY number of NT based OS, NT/2K/XP/2003 (installing in not primary partition is possible and easy) 4) ANY number of Linux based OS (installing in not primary partitionis is default) 5) BeOS on another primary partition 6) You still have a "spare" Entry in partition table. If you don't need/want Dos 6.22 the "small" Priamry partition can be FAT32. The above can be done with a simple bootmanager, like the standard NTLDR, or Grub4DOS that has more features. Cannot say about MacOS X, but since it is Linux/Unix based it should be possible also. jaclaz

I think you got this wrong, if I were a virus and wanted to destroy data on your disk I wouldn't care being able to READ actual data (i.e. no need to have a filesystem driver), I would just write "random" values to your hard disk through RAW write access. Yes, this is done in a number of embedded systems, nice idea ,but probably won't work with Win2k/XP, as they usually need Write access to the MBR, but I am not really sure about this , maybe they need this only during installation to write, besides MBR code, the Disk Signature. The idea of having "expendable" data in the first 1 or 2 Gbyte helps also because it takes time to wipe or write values to a hard disk and there is a possibility of "pulling the plug".... jaclaz

Just for the record, it is possible to use SOFTWARE Raid even if you don't have a Raid enabled motherboard/controller: http://www.msfn.org/board/index.php?showtopic=52012 jaclaz

At the moment, Grub4Dos does work on NTFS, it seems like that tests with Vista NTFS formatted partitions has led to finding some problems, so it has been suggested to NOT use Grub4Dos on NTFS partitions. The dropping of NTFS support is planned, but not yet implemented, if in the meantime either MS releases some details of NTFS or independent projects like ReactOS will make progresses it is very possible that NTFS support won't be dropped. However, since something like 12 years, I personally follow the GOOD advice from Gilles Vollant (the authour of Winimage and of BOOTPART) of always having a smallish First Active Primary Partition FAT16 and install NT based system on a Logical Volume inside Extended Partition, and this has saved my data more than once, as it makes MUCH easier to fix the boot "part" (pardon me the pun) when a problem arises. Moreover, as I continue telling everyone (mostly unlistened to ) having the system and data on a Logical Volume is safer if a "dumb" virus strikes, see here: http://www.msfn.org/board/index.php?showtopic=22526 http://www.msfn.org/board/index.php?showtopic=33964 Yes, correct, but you can use grldr.mbr instead of the ones I suggested. The "problem" with grldr.mbr is that it is 6,144 bytes long, so it occupies apart from the MBR sector, also the following 11 "hidden" sectors, this makes it incompatible with a certain number of Commercial utilities that WITHOUT ACTUALLY TELLING YOU use these sectors for storing some data, if I recall correctly, Partition Magic and Acronis are two commonly used ones that have this behaviour. The two bootmanagers I suggested, besides being Freeware, are contained in MBR 512 bytes. @jim0615 Yep, that's actuallly the idea behind the WHOLE thread. For the record, if you want to read the little experiments I did with the help of sisal, starting from here: http://www.911cd.net/forums//index.php?sho...4181&st=603 You'll find an almost complete solution, that of course needs to be custom adapted to your particular setup. jaclaz

Yep, the intended link was this one : http://www.msfn.org/board/index.php?showtopic=41208 Sorry for the mis-copying. However, I quicly contacted the International Society for Cow Protection: http://www.iscowp.org/ and they assured me that NO cow, mad or sane, was actually harmed in the process, so everything should be well now. jaclaz

What I use is Grub4dos as a boot manager, chainloaded by the normal NTLDR: http://grub4dos.jot.com/WikiHome this avoids the need of as it can boot an image file, but you can use a one-sector-only replacement MBR, like PARTITA: http://www.pedrofreire.com/crea1_en.htm or the newly revamped OS-BS, now renamed mbldr and Open Source: http://sourceforge.net/project/showfiles.php?group_id=162108 About freeware alternatives to Ghost, in my view, best options are: Win32 SelfImage http://selfimage.excelcia.org/ site is down at this moment, get it from here: http://icculus.org/homepages/kfitzner/selfimage/ http://icculus.org/homepages/kfitzner/self...lfImage-111.zip DriveimageXL http://www.runtime.org/dixml.htm Linux PARTIMAGE http://www.partimage.org/Main_Page Support for NTFS is still tagged as "experimental", but I never had a problem with it. both following mini-distros use PARTIMAGE as the main tool: SystemRescueCD http://www.sysresccd.org/Main_Page PING http://ping.windowsdream.com/ However you hit the nail right on the head, it appears that all freeware apps are slower than Ghost: http://www.911cd.net/forums//index.php?showtopic=16534 though things have bettered, but of course if your time is precious, I guess you can pay for the Ghost license. jaclaz

Well, no, the idea is similar, the difference is that you can make everything with freeware or Open Source Software. jaclaz

I beg your pardon? jaclaz

Yep, it is also possible that on a system with a relatively small amount of RAM, disk swapping increased, and that would reduce system "responsiveness" to a crawl. Just to give you an example I tried once the same "reduced", normal and UPXed windows 2K setup on three machines: 1) VIA EPIA with 533Mhz Processor, 256 Mb RAM, ATA 66 drive 2) VIA EPIA with 1000Mhz Processor, 512 Mb RAM newish (at the time) ATA100 drive 3) "standard" ATX with 2,8 Ghz AMD Processor, 512 MB RAM, ATA 133 Drive on 1) the UPXed version was slowish once a few apps were loaded, most probably for the combined effect of CPU overhead and to the HD swapping (not enough RAM) on 2) the speed difference was negligible, could not distinguish between the two on 3) the UPXed version was apparently a bit faster I did not actually made any measurements , the above were just my "feelings", at the time what I was interested into was to build a minimal Win2K that could fit in a ZIP disk, the "final" version running from ZIP disk, proverbially slow, was definitely faster in the UPXed version. I wonder how this would play with XP on newish fast processors and SATA drives.... jaclaz

@jdoe This is not necessarily true, given the relatively slow transfer speed of disks when compared to the relatively high speed of today's computer processors, the "break even point" must be calculated. The real problem with UPXed files is the amount of RAM that is needed to run them, and a general form of "dirtying" memory pages, that could lead to instability problems, you will find this small article interesting: http://f0dder.reteam.org/packandstuff.htm @Francesco Sorry to say so, but your idea is not really new: http://www.msfn.org/board/index.php?showtopic=4120 the problem, you see, is that not all system files CAN be compressed, as some, apart from the considerations above exposed, won't simply work. Some work, with regards to a limited sub-set of XP files has been done in the Winbuilder (was Openbuilder) project: http://boot-land.net/forums/index.php http://www.boot-land.net/forums/index.php?&showforum=22 but you will understand that extending that to the hundreds of files that are part of a full-blown XP is quite a HUGE amount of work, even because some files are not normally used and an eventual bug (compressed file that should have not) would take months to be discovered. Moreover, during development of UPX scripts in the said prohects, it has become eveident that some Windows 2003 files behave differently form XP SP2 one, it is possible that newish releases (Windows Update) of a .dll that was in the earlier version "UPXable" are not anymore. jaclaz

Vingren I have the feeling that you have not a correct view of what the MBR and FDISK do, if I may, I'll try and clear some points. 1) there is no such thing as a "C: split into 2-3 partitions", C: is the latter assigned to ONE of the partitions (more precisely First Active Primary Partition) of First PHYSICAL Hard Drive 2) The MBR consists mainly of two parts: 2.1) Some boot code, that can vary depending of the OS installed or if any boot-manager is installed 2.2) The "partition Table", i.e. an "Address list" holding the data about partition(s) on the drive 3) There are 4 entries available in the partition table, thus there is a maximum of 4 possible partiions on the Drive, unless ONE of the entries, instead of being a Primary partition is an "Extended" one. 4) First sector of Primary partition is the bootsector 5) The Extended partition has NOT a bootsector as first sector, but rather a "Secondary MBR", where more place for "Addresses" is given, these are referred to as "Logical Volumes" inside Extended partition 6) FDISK simply does the following: 6.1) Writes the boot code 6.2) Writes the address of partitions, dividing the Physical Hard Drive into one or more partitions 6.3) DOS/Win9.x/ME has the limit of making only ONE Primary pasrtition and ONE extended one (in which you can make more than one Logical Volumes, Freedos FDISK allows for more than one Primary partitions, only ONE Extended partition is allowed anyway 6.4) Writes the TYPE of partition, i.e. the filesystem that will be used on it, DOS has ONLY FAT16 support, whilst Win9.x/Me has both FAT16 and FAT32 support 6.5) Sets the Primary partition as "Active" or "bootable" 7) Each of the partition which address has been defined by fdisk needs later to be formatted by the FORMAT command or other similar utility, the FORMAT will create the bootsector and the filesystem structures 8) When the computer boots up the "boot code" of the MBR seeks into the "Partition table" for Active partition and passes control to its bootsector You might be interested in this thread: http://www.911cd.net/forums//index.php?showtopic=16713 An alternative could be using DISKPART from, as suggested, a PE build: http://www.msfn.org/board/index.php?showtopic=80363 Or using a third party tool. Another possibility is to use Grub4Dos grldr as the no-emulation bootsector of the CD, loading a floppy image containing FreeDos/DOS/Win9.x/ME, FreeFdisk and grub.exe. Grub.exe has the possibility to chainload Windows NT/XP/2003 setupldr.bin without re-booting, so that you can have a "main" menu.lst, accessed by grldr, that automatically boots the floppy image, in the floppy image in autoexec.bat you put: a.) the free fdisk script you want b.) a call to grub.exe that loads another menu.lst that by default calls the SETUPLDR.BIN and starts the install Please note that you will have to experiment a bit with the above, since "normally" FDISK NEEDS a re-boot in order to update through BIOS the Partition Table. jaclaz