jaclaz

Read the above topic. jaclaz

Also, do not accidentally 93MB of .rar files ... http://knowyourmeme.com/memes/i-accidentally jaclaz

Yes, count me in. It is EXTREMELY repetitive. You have posted this or similar XP fanboyism all over the board. We got the concept by now , there is no need that you post it again and again, even if it is formally correct, it is no real news, and it is additionally rather hard to accept it when coming from someone that didn't actually use NT 4.00 or Windows 2000 (which were actually leaner and faster than XP, BTW) . jaclaz

Yep but both accept command lines (or for exact file there is a command line version), you write a three (or four) line batch and you are all set off. Specifically exactfile command line version can do the comparison against an existing "digest" file: http://www.exactfile.com/exf/exf-command-line-usage/ jaclaz

Get hashmyfiles: http://www.nirsoft.net/utils/hash_my_files.html save the hashes for the two folders/structures. Compare them with a text comparing tool. Or - maybe - Exactfile: http://www.exactfile.com/ The general idea of both is however different, you first hash the "original", saving the hashes to a "digest" file, and then hash the copy comparing its digest to the former one, unlike the "dual pane" view you have in "Checksum Compare". jaclaz

They show up from time to time, what is extremely difficult to find is an "internal" version "plain" IDE/ATA one, what you will find more likely is the external version (for the Mac) with the USB interface, but inside it there is a "normal" 3.5" IDE/ATA device, the issue might be with the front bezel that will need some adaptations. Of course if they come from the US or some other place the shipping will be very high. I can find several ones: http://www.ebay.com.au/sch/i.html?_odkw=imation+superdisk&_sop=15&_osacat=0&_from=R40&_trksid=p2045573.m570.l1313.TR0.TRC0.H0.Ximation+superdisk+drive.TRS0&_nkw=imation+superdisk+drive&_sacat=0 but definitely they are not cheap. jaclaz

NOT a solution, only some reports of previous experience. It happened to me a few times as well. I was not able to find a "real reason" for it to disappear, in my case it was probably (but i have no real way to prove it) some software for low-level USB sticks formatting I installed. There are (rather inconvenient) workarounds, like: https://www.raymond.cc/blog/restore-missing-or-disappeared-safely-remove-hardware-icon/ But before anything else you should clear your USB history and related keys, in many cases this solves the issue (and it is anyway a good thing to do, as otherwise before or later you will experience slow USB mounting, etc.): jaclaz

An additional word of warning (just in case). Once upon a time backups were made on external, removable media (CD's, Zip disks, DVD's, tapes), which had all kinds of reliability problems BTW, but that are effective in the case of cryptoware/ransomware. Nowadays a lot of people I know - while still doing regular backups - have an "automated" setup that consists in a NAS (or however a USB or network connected external hard disk) that they periodically "sync" with the contents of their "main PC". This setup is NOT a good one for these cases because normally the device is connected and mounted to a drive letter at all times. Ransomware will see these devices exactly as what they actually are, connected, mapped volumes and proceed to encrypt them as well. So you need to have these devices either switched off or disconnected (or unmounted) at all times and switch them on/connect them/mount then only when you are actually copying data to them to be "safe". jaclaz

Anyway to sum it up. 1) Using for storage only disks larger than what is natively supported by XP (32 bit) - please read as PosReady 2009 - is "generically" possible 2) to do so such disks need to be partitioned GPT style 3) to create such GPT style partitioning, gdisk is recommended (and nothing else) 4) to be able to access such disks a third party driver is needed, the Paragon GPT loader has been widely tested and works fine Alternatively to the above and limited - I believe - to USB connected hard disks, some 4K native disks can be used, with the caveat that a number of "old" tools that believe that all disks should have sectors 512 bytes in size may malfunction of give errors. This said, it is not "smart" to use any of the above solutions on a "production system", as the advantage of having a single disk is vastly inferior to the risks that using "old" software on these devices may create. Of course if the disk is used - say - just for backups these risks are minimal to none. jaclaz

It is complicated, but can be managed with a little of patience. There are two "styles" for partitioning, MBR and GPT. The MBR has fields 32 bit in size, do they can hold a maximum of 2^32-1 values, since the MBR fields are related to sectors, actual size accessible depends on size of the sectors. A "normal" disk with 512 bytes sector will hit this limit at 4294967295*512=2199023255040 (the infamous 2.2 Tb) a 4k disk will hit this limit at 4294967295*4096= 17592186040320 The BIOS and most of the initial booting code expects sectors to be 512 bytes and cannot boot on "native" 4K disks. The GPT has 64 bit fields, thus allowing up to 2^64-1=18446744073709551615 sectors (waaay more than any existing device). Support for GPT has been introduced with Server 2003/XP64 and it is limited to storage media only (because even if the sector is 512 bytes the BIOS and most of the initial boot code know nothing about the GPT style). Even if it is not "confined" to EFI/UEFI the GPT stye is part of the EFI/UEFI specifications and the good MS guys insist that you need UEFI to boot from a GPT disk, though this has been proved to be not entirely correct as ways have been found to boot later MS OS (7/8/10) from .vhd on GPT disks on BIOS, but these methods are not supported by MS, they are - to say the least - experimental and very risky, JFYI: http://reboot.pro/topic/19516-hack-bootmgr-to-boot-windows-in-bios-to-gpt/ When it comes to XP64 (or Server 2003) a number of other things may add complexity, particularly if the same (GPT) disk is accessed by different later OS, since up to XP/2003 the convention was to align partitions on head/cylinder boundary, whilst starting with Vista it changed to "Mb aligned". Persnally I would not trust the XP (or server 2003) built-in tools to partition a GPT style disk, but I would rather use the excellent Gdisk by Rod Smith: http://www.rodsbooks.com/gdisk/ once the partitions are created, the built-in format is OK. jaclaz P.S.: In certain cases it is possible to use Hybrid MBR/GPT style to boot in BIOS from a GPT style disk, but it is another complex thing which is prone to issues (particularly in case of multi-booting) and due to the way Windows manages Hybrid MBR's you face anyway the 2.2 Tb issue: http://www.rodsbooks.com/gdisk/hybrid.html

There has been some misunderstanding/confusion, probably my bad. The 2.2 Tb limit is related to MBR style of partitioning. The fields in the partition table are 32 bit. The GPT style has not this limit. There are no issues with Server 2003 (at least SP1 if 32 bit) (or XP 64 bit) on a STORAGE ONLY device to use the GPT style of partitioning. For 32 bit Windows XP the Paragon GPT loader (or something equivalent) is needed. All of them cannot however be "system" disks nor "boot" disks. Just for the record not really-really , there are (complicated) ways to boot GPT disks in BIOS through Hybrid MBRs and/or using third party bootmanagers, still the base issue remains, the NTLDR does not understand GPT. jaclaz

Yep, JFYI I heard that JFK was actually kidnapped by aliens and that all the Dallas thing was a cover up. jaclaz

NO, you didn't. The site is about servicing an image. You either serviced an image OR you serviced an offline install, if you did the latter, you did NOT point the DISM to an image but rather to a path to this offline install. The question I asked you (and that you are perfectly free NOT to answer to, of course) is WHAT EXACT command line did you actually TYPE? It is not difficult, and I don't really care about it, I am only trying to make you understand how: "I did that installation successfully." "Dism /image:<path_to_image> /Add-Driver /Driver:c:\winpe_x86\mount\Windows\driver.inf" "I did use same command given in msdn website." are VAGUE reports that won't be of use for someone else with the same or similar problem, they only add some noise on the internet. Can you post the EXACT command you used? jaclaz

@vwestlife Unfortunately, number of vulnerabilities discovered are rather senseless metrics, often used to shift the attention of people from reality. What matters (and there is not AFAIK reliable data about it) are actual infections/numbers of compromised systems. Usually 1/2 to 3/4 (or more) of the vulnerabilities discovered and published are non-vulnerabilities. If you read the detailed description of them you will see how very often they require a complex set of specific situations that either will never happen in real life or include physical access t the machine. Any and all vulnerabilities requiring physical access to the machine are - in my perverted mind - not real vulnerabilities, as if there is physical access to the machine it is anyway "game over". Remote ones start to be relevant, but only if they are actually doable in real life AND if they are actually used in the wild. @Dibya It is usually a good idea to study the problem before talking of things you are not familiar with, and also READ the resources provided. There is no 2.2 Tb limit in the XP NTFS (the sector related fields in the filessytem are 64 bit anyway). There is a limit in the MBR style of partitioning, this limit is 2^32-1=4294967295 sectors and XP - without a third party GPT driver - does not understand GPT. 4294967295*512=2199023255040 <- MBR style limit for 512 bytes/sector 4294967295*4096=17592186040320 <- MBR style limit for 4096 bytes sector (applies to "native 4k disks") I would be curious however to have you describe which kind of "proof" does the video provide, besides promoting a possibly lousy third party program (certainly the technical description is well below any possible standards). Since you seemingly used the thing presented with the video, you can anyway spend (in a new thread possibly) a few words describing it. BTW, the "Hitachi GPT Disk Manager" is actually the already mentioned "Paragon GPT Manager", that is "simply" a GPT driver for XP, re-known, largely tested and working fine. jaclaz

But ONLY as storage media (a non AF or "native" 4 Kb sector disk is usually non-bootable because of BIOS and NTLDR limitations. I believe). There is a third party driver - however - allowing using GPT style disks on XP, just posted about it here: jaclaz

Well, but that's allright since also Server 2003 cannot (the 2.2 Tb limit is in the 32 bit fields of the MBR "partitioning style"). You can use XP with GPT style disks, but you will need a third party driver capable of understanding the new format, see here: http://reboot.pro/topic/18547-vhd-xp-setup-install-xp-in-vhd/?p=199566 for some info and a possible solution. jaclaz

It is a build of Windows embedded ( it is 5.1), JFYI: http://www.msfn.org/board/topic/171814-posready-2009-updates-ported-to-windows-xp-sp3-enu/?do=findComment&comment=1080982 jaclaz

On the contrary, much needed. You just spoiled the whole thing , since the originally whining peep did not come back (clearly showing how interested he was/is in the file). jaclaz

Well, seemingly you saved a number of .mp4 files on a dvd. That is not a video dvd that can be played on most DVD players, meet dvdflick (an example of a free and open source suitable tool): http://www.dvdflick.net/ jaclaz

I know that. You posted: "/image:<path_to_image>" that would service a (mounted) image, what you actually used was "/image:<path_to_offline_install>", as a matter of fact you used "/image:D:", or *something* like that. What EXACT command line did you use? About Devmanview, if you used the 32 bit version, you need the 64 bit one, if you used the 64 bit one you need the 32 bit one: http://www.nirsoft.net/utils/device_manager_view.html 32 bit: http://www.nirsoft.net/utils/devmanview.zip 64 bit: http://www.nirsoft.net/utils/devmanview-x64.zip jaclaz

@cc333 Not so-surprisingly, being 7 actually Vista SP3, and being Windows 8/8.1 respectively alpha and beta releases of Vista SP5. @rn10950 But that all in all is understandable, it is what you have at a running system that actually counts, the (mammoth) size of install files is only a minor issue. OT, but not much, remember that the actual installed size of modern Windows OS is (understandanly BTW) less than what it really is because of the WinSXS hard-linking, try the same Vista (or 7) install on FAT32, JFYI: jaclaz

Yes and no. The above seems to me like servicing an image, not an offline install. jaclaz

Maybe in order to have that emulation working decently they might end up removing some of the bloat from Windows .... (Hey, a man can dream ... ) Just as a reminder, "average" base OS install size: NT 4.0 180 Mb 2K 650 Mb XP 1500 Mb Vista 16000 Mb ... jaclaz

It depends. Ross, Joey or Chandler are suitable names IMHO, Gene or Clint are probably better, "The Hulk" not so much. http://uncutfriendsepisodes.tripod.com/season4/418uncut.htm Seriously now, in which sense would you expect that to be a problem? jaclaz

Well, just for the record and for your interest (and in case you are wanting to experiment) junctions and hardlinks are available since NTFS was invented and also symlinks are available since XP[1], only - wisely - they weren't used or weren't used so extensively in the base OS install. In the case of a hardlink you cannot really say "which one is the original" as the whole point of the hardlink idea is that only one original exists, with more than one pointers to it. So are the files in the system direectory hardlinks to files in WinSXS or is it the other way round? Chicken and egg problem. As a side note, ever wondered why you cannot install Vista (let alone 7) on FAT32 normally? Here: http://reboot.pro/topic/19643-winsxs-hardlinked-files/ once again it is the stupid WinSXS mechanism, a "solution" for DLL Hell that actually creates more problems jaclaz [1] You will find n sources telling you that symlinks were introduced with Vista (which is false, they were introduced in NTFS in XP times, only the good MS guys didn't provide a suitable driver), the truth is here: http://schinagl.priv.at/nt/hardlinkshellext/linkshellextension.html#symboliclinksforwindowsxp more generally the page is a very interesting resource: http://schinagl.priv.at/nt/hardlinkshellext/linkshellextension.html