jaclaz

I would rephrase the above in a slightly more aggressive couple of questions: How many demented developers are there? And are they really all SO §@ç#ing demented? Getting "sideways" from the strict "OS" field, I would presume that among the reasons why SilverLight is/has been/will be a totally dead language (or *whatever* it is/was/will be) it is exactly because it found very few followers among the deverlopers community, thanks heaven. That is why the contents of my few previous posts are preoccupying , there is no reason for the mentioned: and if not that of luring the inexperienced kids into getting on the bandwagon..... You, know dealers outside the school, LSD and stuff: http://www.snopes.com/horrors/drugs/bluestar.asp I chose this example on purpose, being of course absolutely false, BECAUSE: ... a typical case of fail at failing... Try summing inexperienced developers to a senseless environment, I doubt that the result can be anywhere similar to a good app. jaclaz

Hadn't you noticed , the issue is about a foreigner that reads and writes English through Google Translate. I can assure you that if you feed Rule 11 to Google Translate and get it in pseudo-Italian, between 3/4 and 4/5 of Italians reading it will not be able to understand it, I strongly suspect that the same would happen from English to French Heck , do you think that the Allmighty was kidding with the Tower of Babel thingy? http://en.wikipedia.org/wiki/Tower_of_Babel For no apparent reason , another Rule 11 : jaclaz

The common netiquette used on Forums prescribes the use of small letters, like in any normally written text. IF YOU WRITE IN CAPITAL LETTERS it seems like you are SHOUTING!. Please edit your post, and write in small letters. [Pseudo-french] L'éducation commune utilisée sur les forums prescrit l'utilisation de petites lettres, comme dans n'importe quel texte écrit normalement. Si vous écrivez EN LETTRES MAJUSCULES, il semble que vous êtes en criant! S'il vous plaît éditer votre message, et d'écrire en lettres minuscules. [/Pseudo-french] @Kel&@Walrus Comeon, guys , he is French, and he is obviously having some difficulties with English. jaclaz

Technically, and to be a little picky , what you attached is NOT a MBR. It is first sector of a \\PhysicalDrive, depending on it's contents, it may be: a MBR a bootsector/PBR/VBR all 0's <-equates to "a suffusion of yellow" something else Once the contents of such sector has been analyzed and found to be conforming to a MBR (either DATA or CODE or both) structure or to a PBR (again either DATA or CODE or both) structure, then you will know what it is. MBRwizard parses *whatever* you give it as if it was conforming to a MBR structure, imagine that you want to use an Italian-English dictionary to translate from Spanish to English even if you find some words that are similar or actually the same, the result will be mostly gibberish.... It is still a FAT16 bootsector, the difference with the one on the Caleb, besides the differnces in DATA is the CODE, this one is the "real MS-DOS" code, "MSDOS5.0", whilst the Caleb is "MSWIN4.0", i.e. Win 9x. Another thing to note is that this one is media 240 (Floppy) whilst the Caleb is media 248 (hard disk). Bootsector or PBR structure:Start position: 0x00000000 Position 0 of open file: 0x00000000 GENERAL DATA: Offset Description Value Notes 0 0000 JMP instruction: EB3C90 54 0036 Filesytem: FAT16 510 01FE Magic Bytes: 0xAA55 3 0003 OEM String: MSDOS5.0 11 000B Bytes per sector: 0200 512 13 000D Sectors per cluster: 04 4 14 000E Reserved sectors: 0001 1 16 0010 Number of FAT(s): 02 2 17 0011 Max ROOT entries: 0200 512 19 0013 Small type sectors: 0000 0 21 0015 Media type: F0 240 22 0016 Sectors per FAT: 00F1 241 24 0018 Sectors per Head: 0020 32 26 001A Number of Heads: 0008 8 28 001C Sectors Before: 00000000 0 32 0020 Large Sectors: 0003C300 246528 36 0024 Disk number: 00 0 37 0025 Current Head: 00 0 38 0026 NT signature: 29 41 77 004D Volume Serial: 16561E37 374742583 43 002B Volume label: NO NAME 54 0036 System ID: FAT16 You may find of interest these: and the spreadsheets posted. jaclaz

I assume I can "put" you in the happy bunnies basket! http://www.msfn.org/board/index.php?showtopic=128727&st=10 Sure, you learned a whole bunch of new things, a lot like a crash-course in multi-booting, you need some time to digest the info. It has been a pleasure to try and assist you in your search for the solution , and is not the usual complimentary sentence, I sincerely hope that I will have in 30 or so years the same drive, curiosity and will to learn you just demonstrated. I actually need to bow before your UNcommon spirit of adventure. jaclaz

As expected, it is a "normal" MS-DOS FAT16 bootsector or PBR. Bootsector or PBR structure:Start position: 0x00000000 Position 0 of open file: 0x00000000 GENERAL DATA: Offset Description Value Notes Dec Hex Hex Dec 0 0000 JMP instruction: EB3E90 54 0036 Filesytem: FAT16 510 01FE Magic Bytes: 0xAA55 3 0003 OEM String: MSWIN4.0 11 000B Bytes per sector: 0200 512 13 000D Sectors per cluster: 08 8 14 000E Reserved sectors: 0001 1 16 0010 Number of FAT(s): 02 2 17 0011 Max ROOT entries: 0200 512 19 0013 Small type sectors: 0000 0 21 0015 Media type: F8 248 22 0016 Sectors per FAT: 008A 138 24 0018 Sectors per Head: 0020 32 26 001A Number of Heads: 0040 64 28 001C Sectors Before: 00000000 0 32 0020 Large Sectors: 00044D00 281856 36 0024 Disk number: 00 0 37 0025 Current Head: 00 0 38 0026 NT signature: 29 41 77 004D Volume Serial: 1E0076C5 503346885 43 002B Volume label: NO NAME 54 0036 System ID: FAT16 472 01D8 System File 1: IO SYS 483 01E3 System File 2: MSDOS SYS jaclaz

NO, it is NOT. Make a copy of first absolute sector of the diskette. Put it into a .zip file. Attach the .zip file. Just like you did on the mentioned Caleb thread. MBRWizard tries to interpret or parse *whatever* it finds, assuming it represents a MBR, you need to check the *whatever* AND NOT the "interpreted" *whatever*. jaclaz

Well, you asked for it, so yes, you are wrong! The two utiities are at least THREE. The Winternals/Sysinternals one uses later OS system files: not entirely unlike the Linux "captive" drivers: http://en.wikipedia.org/wiki/Captive_NTFS AFAIK the Paragon and the Datapol/Avira NTFS4DOS use their own drivers. IMHO, writing from scratch filesystems drivers may be a non-trifling chore. I presume that having something like FUSE or DOKAN: http://code.google.com/p/dokan/ http://dokan-dev.net/en/ working on 9x/Me would be a "better" approach, in the sense that (I am told that) writing a filesystem driver on top of it is realtively simple. jaclaz

NO actual need for defense at all, as you evidently very well know : Good if the second or third entries work allright for you, you can delete the BOOTMGR and \boot\BCD from the Windows XP disk, those files are only used by the first entry. Sure, that will be in the BOOT.INI on first disk: or: the default for 2K is "WINNT", but you nay have changed the name of the install directory BUT, it could also be in grub4dos menu.lst EITHER of : title Windows 2000 on third disk first partiton map (hd0) (hd2) map (hd2) (hd0) map --hook root (hd0,0) chainloader +1 title Windows 2000 on third disk first partiton map (hd0) (hd2) map (hd2) (hd0) map --hook root (hd0,0) chainloader /ntldr In practice what this kind of grub4dos commands do is what you used to do manually by accessing the BIOS, i.e. change the BIOS hard disk order by re-mapping disks. jaclaz

For NO apparent reason : I wonder WHICH could be next MS product hosted in the "lower world".... jaclaz

No, maybe there is a misunderstanding, my bad . The page: http://msdn.microsoft.com/en-us/library/windows/apps/hh464942(v=vs.85).aspx has ALREADY had it's contents removed, but it still titled "Dev Center - Metro style apps > Docs", I said "quickly" because they could remove it (without the link to the following *anytime*). What I find interesting is that the above page is linked on the mentioned: http://winrt.codeplex.com/ as a hyperlink titled "Windows Runtime" Since I presume, that apart form the folly of using something called "Visual Studio 11 Ultimate" the good Raffaele Rialdi knows what he writes, I found queer that there is not any mention of "WinRT" or "windows Runtime" on the new pages: http://msdn.microsoft.com/en-us/library/windows/apps/br211386.aspx http://msdn.microsoft.com/en-us/library/windows/apps/hh974576.aspx if not in the latter as: I would also like to highlight the BIG NEWS (still on this latter page): "Apps can talk to each other", I mean WOW, it's not like DOS anymore! Please note how the above page is "in theory" targeted to "developers", I wonder about the "qualifications" that actual developers must have to actually *need* such a technical explanation as "You don’t need to know anything about the target app other than its declared support for the target contract – it just works." It must be a joke of some kind , though I completely fail to get which part is the funny one jaclaz

Good This is strange. Unless the disks are somehow listed in BIOS as 0/2/1. I mean the menu.lst I made for you is: Can you try the following? Choose "commandline" (or press "c") Then issue the commands: root (hd0,0) [ENTER] chainloader /bootm [TAB] It should autocomplete to "chainloader /bootmgr". Try again with the other two disks first partition, i.e. repeat the sequence changing just the number of the disk root (hd1,0) and root (hd2,0) Yes. Yes, but you will need to edit the menu.lst file to remove all entries but the one you found working. To clarify (and for the record): Right now what you are doing (to boot Windows XP) is the "normal" way for XP, i.e.: NTLDR->BOOT.INI->Windows XP what you are doing (to boot Windows 7) is: NTLDR->BOOT.INI->grub4dos->menu.lst->BOOTMGR->\boot\BCD->Windows 7 This is NOT what we initially hypothized that was: For Windows 7: BOOTMGR->\boot\BCD->Windows 7 For XP: BOOTMGR->\boot\BCD->NTLDR->BOOT.INI->Windows XP If you prefer, what was planned was to have BOOTMGR as primary bootmanager (and direct bootloader for Windows 7) and NTLDR as bootloader for XP, what you are having now is instead having NTLDR as primary bootmanager (and direct bootloader for XP), grub4dos as secondary bootmanager and BOOTMGR as bootloader (for Windows 7). Of course, since it is working, you can "stay as you are" . jaclaz

A PE is a Pre-install Environment, as a matter of fact BOTH the Win7 install DVD and the "recovery CD" are a form of PE, to be exact a PE 3.x: PE 1.x <-based on XP/2003 sources PE 2.x <-based on Vista /2008 sources PE 3.x<- based on Windows 7/2008 R2 sources I don't know how exactly a Windows 7 "recovery CD" would behave. I like to give personalities to CD's. These are the 2 current possibilities, as I see it. The Windows XP install CD is a sort of good, well meaning guy, possibly a bit clumsy, like: ok, let's see what I have to do I see, I'll format this partition Ok, now I am copying to it the install files Ok, now I'll make a brand new BOOT.INI with an entry to boot the XP once installed Temporarily I will add an entry to boot the install at reboot Ok, now I change the bootsector (I don't really like doing this but MS makes me do it ) Ok, now i'll set everything for next reboot Hmm, let's see if I everything is OK ooops , I seemingly did *something* I should have not done, let me delete the install files and revert the BOOT.INI removing the install entry The Windows 7 recovery cd is more like an angry, nasty little supponent bastard: Ok, let's see what the heck this moron did to an otherwise innocent Windows 7 install Ha!, the demented guy somehow rewrote the bootsector, let me fix it Not only he did this but he also has an aborted installation of XP (that old scum) Let me delete any trace of that install and do *something* that will prevent it running again I wonder how the good MS guys didn't gave me an arm and a hand, I would have liked so much to slap the id*** user in the face, hard So, yes, next step is to add to the current BOOT.INI the line: c:\grldr="grub4dos" and add grldr in ROOT of the C: drive. Then try installing again. At reboot, choose the grub4dos entry. at the: grub> prompt type: chainloader /bootm and press [TAB] key, it should autocomplete to: chainloader /bootmgr press [ENTER] then type: boot press [ENTER] and you should be back to Windows 7. This way you can examine the system after the XP install failed but WITHOUT having run the "recovery CD", i.e. understand if the install files/directories are deleted by the XP install itself or by the following "recovery CD" boot. jaclaz

Yes and no. The partition table is made of 4 (four) entries, each 16 bytes long. So if you do not want to change the first partition, you need to leave alone the first 16 bytes, I fail to understand the reference to 11 BUT, the PTtable is THEORETICAL ONLY in the CHS part, IF you exceed the CHS limit. The max value that you can sencefully express in a MBR Cilynder entry is 1,023. Since you are beyond the CHS limit: becomes (when you write to a MBR Patrtition Table entry: If you check the PT_Entry_#0 and PT_Entry_#1 sheets, you will easily understand WHY this happens . Newer OS will write the above as: Either should do. In layman terms, you are writing values that mak the OS understand that the CHS addressing is m00t and that it has to use the LBA addresses only, should - for any reason - the partition ID be overlooked. jaclaz

Allow me to disagree (partially) with this: Making use of more powerful hardware is what SHOULD have been done, NOT what HAS been done (particularly by Adobe, they have used this powerful hardware to add more and more bloat to their apps INSTEAD of having them work faster/better). Get Adobe PDF Reader: http://get.adobe.com/it/reader/ (36,94 MB) 10.1.0 <- not even the fatter one, the Adobe Reader X 10.1.3 is a whopping 51.95 MB (+an optional 22 Mb of Google Chrome) and compare it (honestly) against: http://www.foxitsoftware.com/Secure_PDF_Reader/ (14 mb) They USED to make a "lean" thingy, see: http://www.oldapps.com/foxit_reader.php see the same "progresses" made by Adobe: http://www.oldapps.com/adobe_reader.php and compare with: http://blog.kowalczyk.info/software/sumatrapdf/free-pdf-reader.html (2,4 Mb) And of course the nice Krzysztof Kowalczyk is on the same trend: http://blog.kowalczyk.info/software/sumatrapdf/news.html (almost anything since version 1.2 is "added features" that are mostly unneeded or "forced upon" by the changes in usage of the "main" tools) jaclaz

Are you positive that you used bootpart correctly? Can you post the output of the boopart command (run without parameters)? It's strange, it should have worked Sure it did not, NTLDR cannot boot a Windows Vista or 7. Well, this of course makes no difference. Another way . Download the attachment. decompress the files grldr and menu.lst in root of first disk.first partition (the XP volume) add to the BOOT.INI the line: C:\grldr="grub4dos" reboot and choose that entry. At the grub4dos menu try all the entries. Whilst first one may fail, the other two should both work jaclaz g4d_for_Roffen.zip

This is strange. It is possible that you are falling into a queer issue that was found about DIsk Management differences (between the Windows XP and the 7 one, connected to cylinder boundaries) but it's "queer", such a problem should have surfaced also the first time. Are you positive (same size/label) that it is actually the same volume? But yes, this is normal, since there is not "yet" a Registry (for the XP, nor a migrate.inf), the drives are assigned letters with the default scheme, which is, if I recall correctly: assign C: to first primary partition of first disk assign later letters to any first primary partition on later disks assign later letters to logical volumes inside extended on first disk assign later letters to logical volumes inside extended on later disks assign later letter to other primary partitions on first disk assign later letters to other primary partitions on later disks So the partitions that you see under Windows 7 as C/H/F/D should become in XP setup C/D/E/F It seems like *somehow* the setup assumes that first stage has already been run. But when you actually run the text mode part of the setup, can you see on the blue screen (at the bootom) the copying of files? Can you try describing in your words what happens during the text mode part? Well, starting from post #17 You should have had that setting disabled. Please do so and leave it disabled, or anyway set the windows 7 to have it's pagefile ONLY on the C:\ drive. That is an idea alternative to the answer (that I am still missing) to this question: If I get it right after the failed attempt you repair the 7 with it's install DVD to be able to boot again, and I wonder if this latter procedure *somehow* is connected to the issue. jaclaz

Oww, comeon . Get the spreadsheet. Open the sheet PTtables. Enter in cells F4:H4 the CHS geometry of your card: Enter in cell D10 the partition ID (optional) Enter in cell E10 the Active status (optional) Enter in cells F10:H10 the Beginning of the partition in CHS (0/1/1) Enter in cells I10:K10 the end of the partition in CHS (1022/15/63) Enter in cells P16:Q16 the LBA start and end addresses (which you can read in cells P10:Q10 Enter in cells M22:N22 the Start sector ad the Num sectors (ehich you can read in cells M10:N10 or in cells M16:N16) Now go to sheet PT_to_MBR and enter in the cells in row 30 the values you have tested and verified in sheet. Now, compare the cells in the upper part of the sheet with a view of the MBR of your CF card. I took the liberty to make the above, so please attach a file named CHS_LBA_v2_D_CF_16Gb_SFE.xls. In case you wonder the naming convetntion is : CHS_LBA_v2 <-name of the base file D<- Doveman CF_16Gb <. CF card 16 Gb SFE <- Spoon Feed Edition jaclaz CHS_LBA_v2_D_CF_16Gb_SFE.zip

Well, there shouldn't be any other issue. I mean, the CHS geometry has relevance only for "booting", once this has happened (AFAIK) anything in a Windows XP or 7 is "LBA". The idea of getting you familiar with my little spreadsheet was actually that of giving you a (valid ) tool to design yourself your experiments. With it and a disk editor (I like and use Tiny Hexer) and possibly using my Structure viewer scripts: http://reboot.pro/8734/ you have no actual need for MBRbatch/mkimg and you can carry your experiments directly on the CF card ... jaclaz

You might want to rephrase the question, as is it might imply that they actually know what they are doing . So I wouldn't focus on what the intend to do, but rather on what they are actually doing (mindlessly) which yes, it is the depauperating of the Win32 codebase, IF "third party developers" are demented enough to follow this lead. Any developer in his right mind won't even touch something called "Visual Studio 11 Ultimate", example: http://winrt.codeplex.com/ Yes, even words have their weight, and "ultimate" is a marketing adjective that is suitable to a game, or maybe to a graphic card, not to a developing environment..... Now, go QUICKLY, before they change iot again here: http://msdn.microsoft.com/en-us/library/windows/apps/hh464942(v=vs.85).aspx and then go where you are redirected: http://msdn.microsoft.com/en-us/library/windows/apps/br211386.aspx then go to the "What's a Metro style app?": http://msdn.microsoft.com/en-us/library/windows/apps/hh974576.aspx Now, go and find on all the huge MS knowledge base a basic illustrative article that also suggests you how you should sell your app. Then try making 1+1. As I see it, it is - as always - about world domination and stuff like that, they want to get some fee for marketing your product.... jaclaz

NO. You must set settings so that you see both hidden and system files. You want to have "Hide protected operating system files (Recommended)" UNchecked. You should also have normally in root (additionally): pagefile.sys (the page file) $Recycle.bin (the Recycling Bin) System Volume Information (another system/hidden folder) and probably quite a few other files that do not show in your screenshot. OR try doing another thing. Open a command prompt and in it issue: CD /D C:\ [ENTER] DIR /AS [ENTER] and DIR /AH [ENTER] (the above list System files and Hidden ones, respectively) jaclaz

I don't think that there is any particular issue with VDK under Windows 7 (excapt usaul UAC and stoopid driver signing) , but MKIMG/MBRBATCH (the "standard version I wrote) won't work anyway because they use a little .COM executable (and support for .COM files have been removed, if I get that right). You coud see if the "updated" version by Lancelot works (it should): http://reboot.pro/5000/ http://reboot.pro/5000/#entry45422 jaclaz

Maybe (and modestly) if you open the first sector of the \\PhysicalDriven with Tiny Hexer and apply to it my viewers, it might be easier to understand the contents. OR get HdHacker, save a copy of first sector of \\PhysicalDriven, compress it to a .zip and attach it and I'll have a look at it. jaclaz

I am simply trying to put your system in the EXACT SAME situation it was when you succeeded installing XP. The Setup process, on a "completely" clean system works like this (simplified): the partition is formatted. The NTLDR and NTDETECT.COM are copied to ROOT the install files are copied to $WIN_NT$.~BT and $WIN_NT$.~LS a copy of the bootsector is made in $WIN_NT$.~BT (invoking the SETUPLDR.BIN INSTEAD of NTLDR) a BOOT.INI is written pointing to this latter copy of the bootsector c:\$win_nt$.~bt\bootsect.dat="Windows XP Installation/Upgrade" end of firs phase and reboot At reboot, the SETUP is booted NOT anymore from the install media but form the internal disk, then the setup does it's job, deletes the $WIN_NT$.~BT and $WIN_NT$.~LS and writes to BOOT.INI the "normal" XP loading string, in your case multi(0)disk(0)rdisk(0)partition(4)\WINDOWS="Windows XP Professional" /fastdetect On a "second" install, the behaviour is exactly the same, but step #5 above has to deal with a pre-existing BOOT.INI. Since you reported that after a failed reboot after the first stage the contents of the BOOT.INI are: multi(0)disk(0)rdisk(0)partition(4)\WINDOWS="Windows XP Professional" /fastdetect AND NOT: c:\$win_nt$.~bt\bootsect.dat="Windows XP Installation/Upgrade" I am suspecting that *something* is preventing the SETUP from editing the pre-existing BOOT.INI. Since you originally had not any BOOT.INI and it worked, and now that you have one it doesn't work anymore, the obvious step is trying again without any BOOT.INI. BUT, still something is not right. The setup (first stage) does create the $WIN_NT$.~BT and $WIN_NT$.~LS folders. Have you also checked on the "H:\ drive "? (or, better on "all" drives?) the location where these directories are made is - if I recall correctly - "automagically" determined by the Setup. These files are deleted after the second (GUI) phase, so if you never get to it, they should remain there (and possibly cause issues). Which means (like a PE of some kind) have you available when you, after having completed the first phase and you cannot boot anymore because of the error, you need to re-access the disk? Alternatively to the above, and provided that you stil have currently the grldr in root of C:\ and that your BOOT.INI is still: and you try again to install XP, at reboot after first stage you should be able, by QUICLY press the arrow down key, to access the BOOT.INI choices and chiise the grldr one. The result should be a command prompt like: grub> can you confirm this? jaclaz

Yes, AFAIK -+- (+ in the middle) was the only availability of the package, it was designed originally to avoid possible polarity exchange when assembling the board. jaclaz