jaclaz

Yep . That's a MS decision , if you check the "alignment jumper" that there is on some 4 Kb sector HD's (I seem to remember Seagate), you will see that they add a "fake" sector so that older OS (XP, that has hardcoded 63 as "boundary") will partition disk starting from sector 64. Since this has been made by the actual HD manufacturer, it means that 64 is "good enough". Yes/No. There is NOT any gap between two primaries. (the previous is already aligned at start and has a size that is a 4 Kb multiple, so also it's end is aligned, hence the following is already aligned). There is no "gap" between a primary and an Extended (for the same reason) but there is a gap inside the extended until the beginning of the first Logical Volume and between any two Logical Volumes. These gaps were 63 sectors in the "previous standard" and are probably (but I have never had an occasion to check) 2048 in the "new standard". This is a common doubt. Traditionally we have seen (because they were like that ) that the MBR is first sector of a hard disk. It is NOT like that (it is , but we have to slightly change the definition) The MBR is the first 512 bytes of the first sector of a hard disk. When we say that the "magic Bytes" 55AA are the last two bytes of first sector, we commit a mistake they are the last two bytes of the MBR, or even more properly the bytes at offset 510 and 511 of the first sector of a hard disk. The above, that now may seem obvious, comes (extrapolated by yours truly porting it from "bootsector" to "MBR") UNexpectedly by a seemingly not connected MS doc , the FAT32 specification: http://download.microsoft.com/download/1/6/1/161ba512-40e2-4cc9-843a-923143f3456c/fatgen103.doc Though evidently written by a snotty MS kid that thinks to be much smarter than his intended audience , and provides among senceful info also a few wrong or misleading info, it contains this: jaclaz

All DOS (MSDOS) up to and INCLUDING MS-DOS 6.22 need IO.SYS as first file and MSDOS.SYS as second. Starting from MS-DOS 7.0 (Windows 95) this is not needed anymore. In a nutshell the bootsector code was changed in 7.0 and could access IO.SYS no matter where in Root Entries it was, whilst previous DOS versions needed both IO.SYS and MSDOS.SYS as first root entries. (and only IO.SYS is used, MSDOS.SYS having become a ".ini" file) http://thestarman.pcministry.com/asm/mbr/index.html#Flop http://thestarman.pcministry.com/asm/mbr/DOS50FDB.htm http://thestarman.pcministry.com/asm/mbr/WIN98FDB.htm Using the FORMAT command MSDOS 5.00, when using NO switch (AND giving a label) creates: the given label in the bootsector a first entry in "Root"with the SAME label as the bootsector MSDOS 5.00, when using ONLY the /B switch (AND giving a label) creates: the given label in the bootsector a first entry in "Root" pointing to IO.SYS a second entry in "Root" pointing to MSDOS.SYS a third entry in "Root" with the SAME label as the bootsector makes the needed FAT table "allocated" for the mentioned two system files writes some "garbage" where the two files should go MSDOS 5.00, when using ONLY the /S switch (AND giving a label) creates: the given label in the bootsector a first entry in "Root" pointing to IO.SYS a second entry in "Root" pointing to MSDOS.SYS a third entry in "Root" pointing to COMMAND.COM a fourth entry in "Root" with the SAME label as the bootsector makes the needed FAT table "allocated" for the mentioned two system files AND copies them, as well as COMMAND.COM MSDOS 6.00 when using NO switch (AND giving a label) creates an IDENTICAL formatted floppy as 5.00. MSDOS 6.00, when using ONLY the /B switch (AND giving a label) creates a SIMILAR formatted floppy as 5.00 (the "garbage" is different) MSDOS 6.00, when using ONLY the /S switch (AND giving a label) creates a SIMILAR formatted floppy as 6.22 (including the DRVSPACE.BIN entry the given label in the bootsector a first entry in "Root" pointing to IO.SYS a second entry in "Root" pointing to MSDOS.SYS a third entry in "Root" pointing to COMMAND.COM a fourth entry in "Root" with DBLSPACE.BIN a fifth entry in "Root" with the SAME label as the bootsector makes the needed FAT table "allocated" for the mentioned two system files AND copies them, as well as COMMAND.COM AND DBLSPACE.BIN MSDOS 6.22 when using NO switch (AND giving a label) creates an IDENTICAL formatted floppy as 6.00 (and 5.00). MSDOS 6.22, when using ONLY the /B switch (AND giving a label) creates a SIMILAR formatted floppy as 6.00 and 5.00 (the "garbage" is different) MSDOS 6.22, when using ONLY the /S switch (AND giving a label) creates: the given label in the bootsector a first entry in "Root" pointing to IO.SYS a second entry in "Root" pointing to MSDOS.SYS a third entry in "Root" pointing to COMMAND.COM a fourth entry in "Root" with DRVSPACE.BIN a fifth entry in "Root" with the SAME label as the bootsector makes the needed FAT table "allocated" for the mentiuoned two system files AND copies them, as well as COMMAND.COM AND DRVSPACE.BIN MSDOS 7.0 (Win95a) when using NO switch (AND giving a label) creates a SIMILAR formatted floppy as 6.22, the LABEL is both in the bootsector and as first entry. MSDOS 7.0, when using ONLY the /B switch (AND giving a label) creates a SIMILAR formatted floppy as 6.22 (the "garbage" is different and is very few bytes) MSDOS 7.0, when using ONLY the /S switch (AND giving a label) creates a SIMILAR formatted floppy as 6.22 (including DRVSPACE.BIN) MSDOS 7.01 (Win95b) when using NO switch (AND giving a label) creates an IDENTICAL formatted floppy as 7.00, the LABEL is both in the bootsector and as first entry. (BUT the boot sector code is different) MSDOS 7.01, when using ONLY the /B switch (AND giving a label) creates an IDENTICAL formatted floppy as 7.00 MSDOS 7.01, when using ONLY the /S switch (AND giving a label) creates a SIMILAR formatted floppy as 7.00 (including DRVSPACE.BIN) MSDOS 7.1 (Win98FE 4.10.1998) when using NO switch (AND giving a label) creates an IDENTICAL formatted floppy as 7.01, the LABEL is both in the bootsector and as first entry. ( BUT the boot sector code is different) MSDOS 7.1, when using ONLY the /B switch (AND giving a label) creates an IDENTICAL formatted floppy as 7.01 MSDOS 7.1, when using ONLY the /S switch (AND giving a label) creates a SIMILAR formatted floppy as 7.01 (including DRVSPACE.BIN) MSDOS 7.1 (win98SE 4.10.2222) behaves exactly as 4.10.1998 MSDOS 8.0 (Windows ME 4.90.3000) creates an IDENTICAL formatted floppy as 7.x MSDOS 8.0 has NOT anymore a /b switch. MSDOS 8.0 has NOT anymore a /s switch. (the test was made with the Me bootdisk, so it is not "definitive") Quite interestingly the "garbage" that is written when the /b switch is used has a size that is NOT exactly the same as the actual files that it "fakes". NOW the tests running on each OS the SYS command on the floppy previously formatted by the SAME OS, WITHOUT ANY switch AND writing to the empty formatted floppy a "random" file before running the SYS, as to have first entry the label and second the file:. MSDOS 5.00 System transferred (no error) <- this is UNLIKE MS info, the root entries are re-ordered with IO.SYS first, MSDOS.SYS second and LABEL third. MSDOS 6.22 same as above. MSDOS 7.0 root entries are NOT reordered (as expected) LABEL remains first entry. .... MSDOS 8.0 has NOT anymore a SYS command working on B: drive. (the test was made with the Me bootdisk, so it is not "definitive") What happened in DOS 6.0 (and EVIDENTLY also though undocumented by MS in 5.00) was simply the same behaviour as bootpart, when you use the SYS command the root entries are shifted so that IO.SYS is first and MSDOS.SYS is second, and the volume needs not having being previously prepared with the /B switch. I will see if I can get my hands on a 3.3 and 4.0 or 4.01 boot disk and check that oooold versions. I tested DOS 4.01 in the meantime. It works allright WITHOUT needing the /B switch. The effect of format /s is IDENTICAL to the 5.00 version (bootcode is different). By doing SYS on a "no-switches" formatted floppy after having copied to it a file the IO.SYS and MSDOS.SYS are correctly "bubblesorted" to the top. Queerly whilst with format /s the COMMAND.COM is copied, with the SYS on the pre-formatted floppy it is not (and needs to be copied manually and as expected "goes last", i.e. after the label and the copied file). I managed to get a 3.3 version but it is not really-really DOS, it's a NEC OEM DOS, and in it the /b switch seemingly does not work. (or possibly it needs some additional parameter, I'll have to check) Also, this verson of format does NOT prompt for a LABEL and there is no label command in the image I found. BUT finally I found what we were looking for, when trying to SYS the floppy previously formatted with no switch and to which I had copied a file, I finally got: So all in all, AS EXPECTED, the MS info is either inaccurate or deceiving or late or all of them at the same time! BTW I found while checking another couple "strange" things. ALL DOS versions tested have an attribute of the label as 0x28 (i.e. Archive+Label), whilst XP uses the 0x08 (Label Only). This has a nice side effect. If you access the floppy image with 7-zip you can actually see the LABEL, it's created date & time, modified date & time and the last accessed date. XP, though it writes 0x08 treats the 0x28 just as the 0x08, i.e. somehow the 0x08 is "prevailing" on the 0x20 @All This is as always a quickly put together report, if you spot any error/typo/whatever in the above, please post about it and I all correct it. jaclaz

Given a partition that has just been formatted, if you just copy IO.SYS alone to it, using DOS, it'll be copied as a single continuous image, starting at cluster 2 (the first cluster). Now, to put in a continuous image of any file, starting at an arbitrary cluster number, especially when the partition in not empty anymore, that requires a lot more calisthenics and patience, but can be acomplished by hand, with a good hexeditor/sector-copier, by anyone who has a really strong reason to do it (like learning how-to, for instance). Or you can use bootpart (as said) to "rewriteroot" (i.e. to put the IO.SYS as first file). A set of related handy (though a bit complex to use/potentially dangerous) are here: http://www.partitionsupport.com/utilities.htm @egrabrych Sometimes (read often) reality becomes a myth, the fact that traditionally an OS behaves in a given way makes people assume that the new version will behave the same (actually this happens often) but some things "remain" and little by little it becomes a myth. Recently while doing a few experiments with DOS FORMAT /B I found another little quirk (obslete info perpetuating). I will post this in a new thread as to not clutter this one. jaclaz P.S.: OK, posted here:

Good. jaclaz

Naah, it is an OLD requisite, up to DOS 6.22 IO.SYS had to be FIRST file in FAT. Compare with the bootpart.txt attached to bootpart: http://www.winimage.com/bootpart.htm This requisite is not needed anymore with DOS 7.x/8.0. Cannot say if - in "peculiar" cases - the IO.SYS is put beyond some "limit" (say beyond 512 Mb or 8 Gb or 128 Gb ) something bad can happen . jaclaz

Just for the record, Examdiff is Freeware and have similar (or at least "enough") comparison capabilities: http://www.prestosoft.com/edp_examdiff.asp jaclaz

Sure , partition info was developed WHEN the "standard" was n/255/63, it is normal that it tells you that the current partitioning scheme does NOT respect cylynder (255/63) or Head (63) alignment. The partition is ALREADY aligned. The (FAT32) filesystem clusters most probably WON'T be, and if you re-format (still FAT32) it under windows 7 NOTHING will change, as I tried to explain you. If you re-format (no matter if under XP or 7) as NTFS, filesystem clusters will be (inherently) aligned. Further explanation: due to how NTFS is made, data clusters are alway aligned on 4K multiples from the beginning of the partition, hence, IF the partition is aligned, so will be the filesystem clusters (the bootsector, i.e. reserved sectors is a multiple of 4Kb, being 16 x 512 bytes long and all other structures are actually "files"). on FAT there are a number of data structures (bootsector/reserved sectors, FAT tables and - on FAT12/16 only - root directories) that are placed BEFORE the actual data clusters and that may not result as being a multiple of 4 Kb, hence, even if the beginning of the parition is aligned, filesystem clusters may not. This is the essence of the referenced thread. I hope now it is more clear. jaclaz

You do not "export" data in .csv format, you actually "Save as" .csv the actual spreadsheet (single sheet). About importing it greatly depends on HOW EXACTLY the soource data is formatted, no way to give you any "meaningful" answer without some DETAILS. Excel has a built-in import filter for either "fixed length" or "delimited" data, but it's behaviour may be influenced by a number of factors, including repeated separators and what not. Also in some cases Excel "automagically" determines *something* to be text or date or number and makes the importing procedure more difficult/prone to error. You may need to use a "more dedicated2 program such as: http://record-editor.sourceforge.net/Record02.htm to do an intermediate conversion. jaclaz

You mean that you do not trust my word for it? BTW I provided a link, that - had you actually checked it - may have lead you to here (from the mouth of the wolf, but you will need to "read between the lines"): http://support.microsoft.com/kb/931760/en-us Vista and 7 have a Registry key: HKEY_LOCAL_MACHINE\SYSTEM\CURRENTCONTROLSET\SERVICES\VDS\ALIGNMENT which you can use to override default partition alignment (which is respecting the 4K multiple). Additional (JFYI): http://www.techpowerup.com/forums/showthread.php?t=107126 The MBR will use 512 bytes sized sectors. Block (or sector) size has nothing to do with cluster size. I am NOT "insinuating" anything, I am stating (rather flatly )that the internal structrures of a FAT (12/16/32 and presumably 64) may (actually will in, say, 90% of cases) produce the effect that the filesystem clusters NOT to be aligned properly (and provided a link that explains in detail the issue). jaclaz

Yep , additionally, the issue with SSD is not exactly the "same" one as with HD's. The use of a TRIM enabled OS (like Windows 7 is) AND enable it may make a BIG difference (after some time): http://reboot.pro/9615/ Direct link to the article: http://www.anandtech.com/storage/showdoc.aspx?i=3531&p=1 More: http://blogs.msdn.com/b/e7/archive/2009/05/05/support-and-q-a-for-solid-state-drives-and.aspx And how to make sure TRIM is running: http://blog.corsair.com/?p=3468 http://lifehacker.com/5640971/check-if-trim-is-enabled-for-your-solid-state-drive-in-windows-7 jaclaz

By default Windows 7 will align the start of the partition to a 4 K boundary. Namely first partition will start at CHS 0/32/33 or LBA 2048. (and all following partitions will all be aligned as well) Having a partition aligned as above makes sense if the partition is NTFS formatted. If you need/want to use a FAT filesystem you will need to align the fiilesystem clusters (additionally): To check the alignment you just inspect the MBR (and the eventual EPBR(s)) and verify that the "Sectors Before" or "LBA start Address" can be divided by 8. A suitable tool could be PTEDIT32 or any similar partition table editor/viewer. Maybe better if you use partinfo (so that there is no risk to edit a field by mistake): ftp://ftp.symantec.com/public/english_us_canada/tools/pq/utilities/PartInNT.zip I don't know if it runs on 7, but it should. If -by any chance - you are going to use Logical Volumes inside Extended (partitioned/created under 7) AND use on the disk the XP disk manager, be VERY aware of the possible issues: http://reboot.pro/9897/ jaclaz

NO. Totally UNdocumented, UNreliable, DO NOT EVEN THINK of doing this! We have a sticky EXACTLY to avoid this kind of senseless and risky attempts. Doing a PCB swap REQUIRES exactly matching PCB's (much less easier to find than you might think) AND REQUIRES a ROM swap, which involves quite tricky de-soldering and re-soldering. If you come here and ask what to do you simply CANNOT (meaning that you miss the NEEDED knowledge/experience involved) in doing this (and you will get it only after you have "fried" several hard disks or their PCB's making practice). jaclaz

Who was actually quoting Douglas Adams Just in case of need : http://www.thateden.co.uk/dirk/ jaclaz

Sounds like hardware issues. http://support.microsoft.com/kb/315266/en-us I would check RAM (try one OR the other memory bank, one at the time) and remove and reseat *everything* first thing, then verify disk/filesystem from an "external" boot (Recovery Console or PE). jaclaz

Cannot say, you should check yourself by connecting the hard disk "directly" (without the USB enclosure) to a desktop and see what the BIOS detects. THIS guide: http://www.mapleleafmountain.com/seagatebrick.html See here: APTLY titled: Also : http://en.wikipedia.org/wiki/There_ain't_no_such_thing_as_a_free_lunch There is NOTHING connected with dial-up, EXCEPTION made for this : You may want to re-read (actually READ for the first time) the mentioned guide. An internet connection may be handy if you need help, but there is no actual *need* for one. Sure you can . jaclaz

When talking of software beauty is very often in the eyes of the beholder. I never had an actual need for such a program, for my use a OFM: http://www.softpanorama.org/OFM/index.shtml (which includes - though not exactly Orthodox - 7-zip ) is enough. However, have a try with this thingy here: http://www.copyhandler.com/en/what-is-copy-handler coincidentally (or maybe casually ) it is written by a Polish guy jaclaz

Yep , as said the issue is WHEN this will happen. BTW, decompilation rights are in some cases ("fair use") given even while the Copyright is in effect. http://en.wikipedia.org/wiki/Decompiler#Legality jaclaz

The 82845G (internal) is among the tested cards for VBEMP: http://bearwindows.boot-land.net/vbe9x.htm You may need to update BIOS or use a TSR, though: jaclaz

Well, if it is PCIe it may be nonetheless accessible by grub4dos (i.e. the BIOS may map it even if it does not allow it in the list of boot devices). It would still be a "mixed mode boot", but better than nothing.... An old attempt (UNfinalized ) here: http://www.911cd.net/forums//index.php?showtopic=20314 jaclaz

At least in the US, a computer program is considered "literary work": http://en.wikipedia.org/wiki/Software_copyright I also presume that specifically it falls in the category of “work made for hire” AND "corporate ownership". Thus it should fall in the category: http://inventors.about.com/od/copyrights/a/expiration.htm First published Windows98 should be 25 June 1998. IF the quoted data is correct, that would mean 1998+95-2011=82 years, better than 87, but still...... jaclaz

HOW is the SD card reader connected (which BUS)? PLoP may be able to boot from it if it is on the USB bus (it would be a "mixed mode" boot, though) jaclaz

Doesn't this require Microsoft to release the source code? Or has it ever been leaked? No. "Public Domain" does not mean that it becomes "Open Source" (and of course DO NOT EVEN THINK of using leaked source , if any ). After a given number of years since publication has elapsed or in some cases after a given number of years since the death of the Author, intellectual property is not anymore protected by Law: http://en.wikipedia.org/wiki/Public_domain I have NO idea where the cited 87 years come from. Cited from here: http://programmers.stackexchange.com/questions/72914/will-a-copyrighted-code-get-into-public-domain-once-its-copyright-expires jaclaz

The 2K drivers are FASTER than new ones, but this applies to FAT32, not to NTFS (and I presume that your 15 Gb archive resides on NTFS): So it must be something else, I doubt that recent hardware (say last 3 years, even laptops) have USB 1.0 speed, if that laptop came with Windows 7 it must be a recent one.... jaclaz

I wonder WHERE you got that file. You want this one CALLED UBCD511.ISO: http://www.ultimatebootcd.com/download.html The page lists a number of mirrors, a few ones: http://ubcd.mirror.fusa.be/ubcd511.iso http://ftp.gr.vim.org/mirrors/linux/ubcd/ubcd511.iso http://pharry.org/data/ubcd511.iso And yes, if you don't have a suitable program, get IMGBURN: http://www.imgburn.com/ http://www.imgburn.com/index.php?act=download You want to get a file that is called SetupImgBurn_2.5.6.0.exe jaclaz

There is a recent thread (not Win9x) related: where you may get anyway some info. Have you considered the idea of running with NO page file? How much RAM is actually used by the system in "normal" operation? Which "kind" (i.e. in which occasion) are "temp" files created? How big in size they can be? 196 Mb on a Windows 98 machine should be enough to run setting aside a small RAM disk for "temp".... jaclaz