jaclaz

Monitors don't really *need* drivers. The video card outputs a (VGA) signal, at a given resolution and refresh rate, a (CRT) monitors can ether "hook" that signal or it cannot, under OS that can recognize the monitor, resolution (and expecially refresh rates) that the monitor cannot support are disabled in the video card settings. On LCD the matter is slightly different, a LCD monitor has a "native" resolution, for a 19 inch "typically" it is 1280x1024 (WxH) or 1280x800 depending if the monitor is 5:4 or 16:10 http://en.wikipedia.org/wiki/Display_size http://en.wikipedia.org/wiki/Display_resolution On LCD, ANY resolution which is not it's "native" one will be interpolated/stretched and what not, in any case it will work with far then optimal visual results, so what you really should take care of is that your video card (and it's drivers) supports the specific "native" video resolution that your LCD monitor has. jaclaz

Sure , no prob , only give me some time to overhaul my wheelbarrow, it needs some work to be ready for race: I must have somewhere an old KTM 360 engine .... that should fit nicely .... jaclaz

Something like this: http://techreport.com/review/16255/acard-ans-9010-serial-ata-ram-disk but made slower by attaching it to the USB (2.0) bus? Possibly with the USB 3.0 they will make something.... jaclaz

Open the physicaldrive in DMDE (since you have it handy), you know like: There is this point that you seem to have not grasped completely : LBA of a sector (on an opened Physicaldrive or image of it) is ABSOLUTE vol sec (on the same sector) is RELATIVE to volume. Hence (in the given example that you provided) 6158983-6158920=63 this is the offset to the beginning of the volume. BUT if you mount the physicaldrive image with IMDISK, because of the specific way IMDISK works, the offset to the volume becomes 0 and thus Absolute LBA and Relative LBA are the same. I hope now this matter is more clear. About further attempts to recover from the failed drive, there are two "levels" of issues: first is to make sure that you are getting the "right" sectors, which you can verify by doing tests with some files that you also already have in the 134 or 500 Gb image second is to hope (you cannot do much more than that) that those sectors are readable and adre not corrupted. Right now it is not yet clear if you are still in the first level or if you are (unfortunately) in the second and the sectors for that particular file are either corrupted or unreadable. jaclaz

I dont want to be grumpier then usual, but I simply represented you the current situation to the best of my knowledge. The ONLY way to have a pagefile on a non-internal disk in a Windows NT based systems is AFAIK the Diskmod filter driver I pointed you to, which is NOT hardware specific and has been tested and verified to be working on: XP 32 bit Vista BOTH 32 and 64 bit 7 BOTH 32 and 64 bit there is NO reason why it should not work on XP 64 in theory, but, as said YMMV. You asked a question, I took some time to answer it, as said to the best of my knowledge, the fact that you don't like the answer or you are uncapable of putting it into practice or simply want to wait someone else to try it, should not prevent you from: ask nicely clarifications if there are things that you don't understand being thankful for the time spent in attempting to help you The fact that you used to program in 8 different machine languages evidently prevented you from learning "foreign languages" and also some common forms of politeness. A lot of people don't know what a filter driver is on a NT based system, but instead of accusing other people of writing in a foreign language, most probably because they never programmed in 8 different machine languages, they tend to try understanding what is written, instead of skimming through and jumping t (bTW completely absurd) conclusions and come back whining. I hope you will have fun while putting a pagefile on an external device (or completely failing at it ).. jaclaz

Wait a minute, now that I think of it , what (the HECK ) is your G:\ drive? (if it is not the first primary volume on a hard disk partitioned with the "traditional" CHS aligned scheme it's offset will NOT be 63 ) The idea is that what myfragmenter gets is the Logical Cluster number, that is ALWAYS relative to the begin of the volume. The myfragi batch translates it to ABSOLUTE LBA (starting from the start of the DISK) by multiplying the cluster number by cluster size and ADDing to it the offset (63 in the case of that disk/volume). If you access the original disk, you need the absolute LBA, if you access an image mounted with IMDISK (that ignores the 63 sectors before) you should subtract from the result of myfragi 63 sectors (or better change the data in the batch, see below) if you are using any disk where the volume does not start at 63 you need to change the offset in the batch (or manually add/subtract the difference), these are variables in myfragi.cmd: A "normal" NTFS formatted volume will have clusters sized 8 sectors (but not necessarily) while the initial offset (where the Volume starts on the disk) is 63 ONLY if it is first primary partition and the disk is formatted "normally", i.e. before Vista , if that disk has been partitioned bu another OS or through a third party utility, the Volume may start at *any* LBA offset. Are you sure you are using the "right" PhysicalDrive? I will reiterate how datarescuedd numbers them starting from 1, whilst Disk Manager and any other utility using the \\.\\Physicaldriven object to access a disk numbers them from 0. jaclaz

JFX, the BOOTSECT.DAT posted by AQM (and as well the bootsector in WinNTSetup.log) are both "wrong". Sectors before are 0 (should have been 63), i.e. at 0x1C there should be 0x3F and not 0x00. jaclaz

Well the good news: http://www.zdnet.com/microsoft-admits-surface-keyboard-splitting-problem-7000007189/ are that they are aknowledging the: the road to actually admit the "mental separation" from user base and reality is still long though... jaclaz

Yes, the behaviour of dmde is "normal", the Physicaldrive (and obviously the my500gb image) start at absolute sector LBA 0, th actual Volume (drive letter) starts at absolute LBA 63, which becomes Relative LBA 0, hence the LBA: 6158983, vol.sec:6158920 63 sectors difference, when you open the Volume, it's initial offset is 0 (as you are not accessing the physicaldrive, but rather a virtual disk through IMDISK, that simply "fakes" that the Volume is a Superfloppy with no sectors before). In theory in datarescuedd you should select NOT the Volume (drive letter) but rather the disk (something like "drive 2"), but it should NOT make any difference. Is it not that the resulting image file is locked by the still open datarescuedd? I'll check if I can give you an alternate tool to try instead of datarescuedd..... jaclaz EDIT: Try with pldd, here: http://home.comcast.net/~plavarre/plscsi/tools/pldd/ The syntax you should use is, given: myfragi.cmd g:\test.jpg 1 52254759 418038135 3104 g:\test.jpg the following (make sure you get the right \\PhysicalDrive number n):

@snoopy55 The ability to put a pagefile on a USB stick is determined by a number of things (ways the OS "sees" the device). What I find very strange (besides what you want to achieve) is what you report. A "normal" MS NT based OS won't allow having a pagefile on an "external" disk, let alone a "removable" one. To allow this normally a filter driver is used, see here for DiskMod: http://reboot.pro/9461/ http://reboot.pro/9461/#entry86619/ which comes also in a 64 bit version, though tested only on later systems (Vista and 7) AFAICR. jaclaz

No, there must be something being lost in translation (either "human" translation or "batch/program" one). It seems to me like you did everything "right". Myfragmenter provides the LCN (that is Logical cluster number). On your disk a cluster is made by 8 sectors and there is an initial offset of 63 sectors to the volume (or start of the Logical Cluster Number). The myfragi batch takes the LCN and converts it in Absolute LBA, i.e. it converts 769865*8+63=6158983 As well it takes the difference beween Vcn's and multiplies it by 8, i.e. if you run directly myfragmenter -i you should get for that file Vcn=0, NextVcn=78 and the myfragi does (78-0)*8=624 And the file should be 624*512=319488 In drdd you use LBA so you should have start 6158983 and length 624. Since this file is already in one chunk, the result should be already the file. But these seem right: The only issue is that since the myfragmenter uses clusters as "unit", the resulting file might be larger (up to the cluster border) than the original, this shouldn't be a problem for images like JPEG, but it may be an issue with other data formats, in which case you use again fsz to "cut" the file to the exact bytes length you have in Explorer or in a DIR command. Could it be an issue with the initial offset? Maybe the my500Gb.img, being mounted in IMDISK (which ignores hidden sectors/first track) shifts the addresses? (but it doesn't "sound" right) Try doing a test with a file on your "main", working drive and or, try accessing the same file with DMDE, the LBA and LCN should be the same as the ones provided by myfragi. If they are, the only sensible explanation is that the reading of those particular sectors from the "original" disk drive are now failing (while they worked when you made the 134 Gb image.... jaclaz

As a matter of fact nothing really "challenging" . The comparison between a Server 2003 32 bit using PAE with a (say) Server 2008 R2 64 bit is one of those "practical impossibilities" in the sense that I have never seen such a comparison done "properly" (if not for "research") i.e. on comparable hardware, usually you have a several years old machine running 32 bit 2003 Server, and you get a brand new machine, install to it 2008 R2 64 bit and this latter is actually much faster, but how much of it is due to the hardware and how much to the 64 bitness is normally to be seen. I would go further affirming that - often - (and obviously I am making here a very generic statement ) servers need to have a very fast storage subsystem and their performance is rarely connected with how fast is their memory access, but rather on how fast is their storage subsystem. When an actually memory intensive use of the server is needed, the advantage of the 64 bit memory addressing is seemingly more in the "capabilities" than in speed, see this as an example: http://www.dell.com/downloads/global/solutions/oracle_performance_em64t_6850.pdf on page 9 there is a nice XY graph showing how the performance (until a "size limit" is reached) is substantially the same. jaclaz

I don't have the Porsche and I quite frankly cannot see a single reason for using my Toyouta Hi-Lux for moving dirt and yard waste across your property. Of course, if you come over here with your wheelbarrow, I will be glad to give you a chance of showing me how fast you are moving dirt and yard waste across my property. jaclaz

Do you want a more "professional" source? Here you are: http://msdn.microsoft.com/en-us/library/windows/desktop/ee719653(v=vs.85).aspx http://msdn.microsoft.com/en-us/library/windows/desktop/ee719901(v=vs.85).aspx I guess that you need to remove the WIC codec http://en.wikipedia.org/wiki/Windows_Imaging_Component jaclaz

Well, BOTH a Toyota Hi-Lux and a Porsche 911 would be way faster than your wheelbarrow (because they have more wheels). For NO apparent reason, but JFYI : jaclaz

Never thought you were a fanboy, as said there is a number of people that actually needed to have the XP 64 (only they are much less than the actual XP 64 user base) you may well be one of the few, and, like everyone else migrating to the new platform you must have had the same driver issues everyone else had, or you were another lucky peep like JodyThornton is? However, as said, no problem if you hadn't actually a need for it and just fancied it. The usual comparison between Porsche 911 and Toyota Hi-Lux (and a wheelbarrow ) JFYI: http://www.911cd.net/forums//index.php?showtopic=24502&st=12 jaclaz

@CharlotteTheHarlot You are evidently not very familiar with mathematics/economy. You would have to add the question: Are you running Windows 7 or Windows 8? to the list of questions that an underpayed, good willing but technically inexperiened help desk operator in an eastern country will have to ask calling customers . That (and the customer answer after having checked) would increase the duration of the call by 10 to 15 seconds. To that you should add the increased costs for the (non-)training of the help desk operators. And drivers for BOTH 7 and 8? Those represent money, BIG bucks. The new solution under study for HP support for windows 7 is a recorded message to the effect of: One size fits all! jaclaz

Not at all. Simply trying to have things called with their names . Is a 64 bit system more "capable" overall than a 32 bit system? Yes. Is a 64 bit system faster than a 32 bit system? Rarely. Is a 64 bit application running in a 64 bit OS faster than it's 32 bit counterpart? Rarely. Does everyone *needed* at the time of XP 64 a 64 bit system? No, only a very few people in the need of running very high end kind of apps might have actually *needed* one, and they would have had to be very careful in finding supported hardware and their drivers, at the time non-existing or rare or buggy. Does everyone *need* (now) a 64 bit system? No, only a few people in the need of running very high end kind of apps or however doing an "intensive" use of a PC may actually *need* one, the good news being that the issues with supported hardware and their drivers are not anymore a common problem. Is a 32 bit app running under a 64 bit faster than on a native 32 bit system? No. But 32 bit systems cannot access more than 3/4 Gb of RAM.... NO. The limit is given in some MS OS's by commercial/technical choices (NOT architecture limits) as - even without any technical knowledge easily verifiable by checking how most 32 bit Server edition support largely more that that, typically 64 Gb: http://msdn.microsoft.com/library/aa366778.aspx But 32 bit systems running PAE are slower than 64 bit systems accessing memory. Not really, or the differences (comparing very similar hardware) are negligible. But I like to have a 64 bit system anyway. That's good :, and you can have one allright , only you should know how most probably you won't be going to use all the increased potentialities of it when compared to a 32 bit system, and you shouldn't say that you chose it because 32 bit OS does not support more than 3/4 Gb of memory, as this is not the case, an OS vendor has introduced some limits to some of the 32 bit OS's it sells for its own (perfectly logical) commercial or technical reasons. jaclaz

Have a look at one of those CD's with a tool like Isobuster (freeware/shareware): http://www.isobuster.com/ you will like find a number of "sessions". jaclaz

Yep The spreadsheet could look something *like*: By LBA Ext: Lcn: LBAstart: Sects: File: Limit: ROffset: ROffsetB: #1 1 495.625 3.965.063 16 f:\montage\2011-tmp.pds 2.766.950.084 - - #3 2 28.135.076 225.080.671 16 f:\montage\2011-tmp.pds 2.766.950.084 16 8.192 #5 3 48.751.063 390.008.567 32 f:\montage\2011-tmp.pds 2.766.950.084 32 16.384 #6 4 48.797.290 390.378.383 64 f:\montage\2011-tmp.pds 2.766.950.084 64 32.768 #7 5 50.038.742 400.309.999 128 f:\montage\2011-tmp.pds 2.766.950.084 128 65.536 #2 6 26.068.714 208.549.775 128 f:\montage\2011-tmp.pds 2.766.950.084 256 131.072 #9 7 94.098.378 752.787.087 136 f:\montage\2011-tmp.pds 2.766.950.084 384 196.608 #8 8 74.619.826 596.958.671 120 f:\montage\2011-tmp.pds 2.766.950.084 520 266.240 #10 9 95.440.487 763.523.959 152 f:\montage\2011-tmp.pds 2.766.950.084 640 327.680 #12 10 106.615.323 852.922.647 104 f:\montage\2011-tmp.pds 2.766.950.084 792 405.504 #11 11 95.441.871 763.535.031 152 f:\montage\2011-tmp.pds 2.766.950.084 896 458.752 #4 12 48.579.698 388.637.647 24 f:\montage\2011-tmp.pds 2.766.950.084 1.048 536.576 where Roffset= Sects+Previous ROffset and ROffsetB=ROffset*512 The "0" means "copy the whole size" of the following "chunk", you could use instead the exact size of the chunk in bytes, but it only makes more complex the command, i.e. it could be: (by coincidence the second chunk is actually 16 sectors i.e. 8192 bytes in size) jaclaz

But you feel like commenting on them nonetheless, "mostly illogical, but fascinating nonetheless" my good friend Spock would comment . Sure , let's make a list of all applications that crash on a 32 bit OS (as all 32 bit OS are the same and particularly all MS ones and the myriad of version that there are of them all behave the same). You should use 64 bit only systems (and also add some RAM to them), if you happen to easily hit 1.7 Gb oin a browser, the whole point was only that this is not "everyday common" and definitely it wasn't in XP 64 times. jaclaz

Good, another one having not read the given links. I cannot post a direct link to the relevant info, because for *any* reason it is considered "hostile" by MSFN. But I can point you to a related MS KB: http://support.microsoft.com/kb/888137/en-us jaclaz

I am not an expert on this, but it seems like Vista uses the IMAPI 2 to write discs in SAO mode, see: http://en.wikipedia.org/wiki/Optical_disc_recording_modes http://en.wikipedia.org/wiki/Image_Mastering_API http://www.osta.org/technology/cdqa2.htm which is basically a multi-session disk . It is likely that the issue you are having are created by the multiple sessions indexes, lead-in, lead out, etc.. Are you positive that you are using CDRW media (and not CDR) ? jaclaz

As a matter of fact the WHOLE JPEG format is made of "dynamic" fields and it is ALREADY complex enough to parse without the good Adobe guys inventing this "feature" and the other good guys from MS adopting it "mainstrem" not before (as said) having dumbified it, by removing from it the actual useful info about the app that did it and pointing to a non existing site. jaclaz

I said READ the given links (AND links within them) then take your own decisions/conclusions/whatever, only please don't give me the usual "32 bit systems cannot access more than 4 Gb of RAM" or the usual generic "64 bit is better". jaclaz