jaclaz

No prob , happy to see you are not only well , but still having the will (or recklessness ) of experimenting with new old PC's. jaclaz

Well, no real need to suppose, "adding" means "adding at the bottom". If you prefer, edit the BOOT.INI in such a way that it's last line reads: Or, given that your current one looks like this: Edit it so that it looks like this: At next boot, no matter if you are currently booting the XP (through the NTLDR) or the 7 (through BOOTMGR) you should have an added choice to choose "grub4dos". Make sure that the BOOT.INI has a decent timeout value, like 10 seconds or more. jaclaz

as if *any* other disease that can be transmitted from person to person would work differently .... Personally I like better the conclusions of a known paper on the matter: https://web.archive.org/web/20090701000000*/http://www.mathstat.uottawa.ca/~rsmith/Zombies.pdf jaclaz

Good that it works fine double clicking, as at the end of the day it will be it's actual usage. Try (to understand what the issue is when Run as Admin is used) to add a few lines like: ECHO Checkpoint#1&PAUSEbefore a few groups of commands and see on which Checkpoint it Pauses last (or what is displayed until the last prompt for the press any key closes the window). jaclaz

Yep. JFYI, this would do as well: (everything should be as simple as possible, but not simpler ) jaclaz

A4. And here is a link to a camel and to a dromedary. jaclaz

@cdob @all Once there will be agreement on the patch, maybe better suited than dd would be hexalter: kuwanger.net/misc/hexalter.shtml possibly even using an ips file. jaclaz

Do you mean that you can see "other" *partitions* but not the "W:" one? Strictly speaking the "W:" is not a partition it is a drive letter assigned to a volume, or even more exactly it is a mounpoint for the volume implicitly created inside the partition you created. Even if the XP setup can see that volume, it will assign to it by default a different letter (much "lower", like E: , provided that you have the hidden windows7 partition, a "normal" largish partition as C: and a DVD drive with letter D: ) But, depending on the size of the hard disk and on where (towards the beginning or the end of the disk) you created the partition you may be affected by the so-called LBA48 barrier, roughly around 128Gb. In any case installing an XP on a disk where 7 has been already installed needs a couple tricks to later allow for dual booting. Can you post some more details on your hardware and describe EXACTLY how you created the added 80 Gb partition? jaclaz

Sure , the launch of Windows 10 is imminent! ... just about the right introduction to Dooms Day.... jaclaz

No notoriously-not-new naive nonresident needs noting narcissistic nonsense ... jaclaz

The matter is "touched" (though not exactly answering your questions) here: http://www.msfn.org/board/topic/128727-cant-access-repair-my-pc-option-via-f8-startup/ starting from around here: http://www.msfn.org/board/topic/128727-cant-access-repair-my-pc-option-via-f8-startup/?p=950736 Particularly, one of the given links: http://www.svrops.com/svrops/articles/winvistare.htm should be of use. jaclaz

Good. Right now the :do_elevate is: you can try with: Is that the effect you want? Both double clicking and RunAsAdmin should work though possibly the first should make use of the ":do_elevate" and the second go "direct", but you need anyway to try... The issue (in theory as I haven't tested yet) with the "second" (actually "third") partition/volume would be different depending on the OS running and the actual bootsector in use. The additional volume would behave just like the NTFS volume did in previous tests at least in theory: under XP: If interface is 512 and bootsector is 512 then volume would be normally visible/accessible/etc. If interface is 512 and bootsector is 4096 then volume can be normally "switched" (&GOTO #1) If interface is 4096 and bootsector is 4096 then volume would be normally visible/accessible/etc. If interface is 4096 and bootsector is 4096 then volume can be normally "switched" (&GOTO #3)under 8.1 (which probably means Vista and later): If interface is 512 and bootsector is 512 then volume would be normally visible/accessible/etc. If interface is 512 and bootsector is 4096 then volume can be normally "switched" (&GOTO #1) If interface is 4096 and bootsector is 4096 then volume would be normally visible/accessible/etc. If interface is 4096 and bootsector is 512 then volume canNOT be "switched" (stuck )The switching (where possible) would most probably create some issues (though nothing that cannot be solved) with drive letter assignments, so it would be easier to have a "fixed" situation #1, also because there would the need for 1 EPBR (for the 512 interface) instead of 2 EPBR's (one for the 512 interface and one for the 4096). The above would apply only if that volume was normally formatted with any of the available filesystems, or anyway if NTFS, if we pre-format via batch we would have to make (just like we do for the first FAT12 Partition) a "dual-mode" formatting, which opens a (small) can of worms, as once excluded NTFS we have available: FAT 12 (but only up to 32 Mb) i.e. "good" only if the first FAT12 partition is up to 32/7=4 Mb FAT16 (but possibly only over 16 Mb), i.e. "good" only if the first FAT12 partition is over 16/7=2 Mb FAT 32 (but only over roughly 268 Mb), i.e. "good" only if the first FAT12 is over 268/7=38 Mb (but then the first FAT12 partition would be a first FAT16 partition)(I have no idea/have not checked what could be done with exFAT) It would be I believe acceptable however to limit the range of sizes for the first partition to 3-32 or 4-32 (instead of the current 1-32) and "force" a FAT16 filesystem on this second partition, this way (which would not require switching) would "restore" the lost area, possibly minus 1 Mbyte wasted by the EPBR to keep the volume "Mb aligned" provided that it makes sense (probably unneeded as a 4kb alignment would do nicely as well). Still some tests should be made to verify that *something else* (the way mount manager *sees* this setup under different OS/interface) gets in the way of this otherwise nicely laid out plan... ... the good news are that at least in theory this added volume could be post-fitted to an existing "dual disk" without modifying the existing data... There would be in any case no "risks" of damages for the contents of the volume, of course, they would be either fully accessible or not accessible. jaclaz

Hmmm , (small caliber) dogguns may go pew-pew-pew, but here we are talking of gundogs, which are another thing. jaclaz

Naah, the real fun is not in just solving the puzzle, it is into creating it beforehand . @Dave-H Find attached Switcher 010, it should be a tadbit less verbose, skipping not really needed operations. jaclaz Switcher010.zip

Hmmm. Q. Anyone with good memory remembers the name of those four legged animals with one or two humps that are suited to transport one or two people or some goods across desert areas? A1. You mean a camel or a dromedary? A2. Why don't you use a Jeep instead? A3. Elephants have 4 legs and additionally a trunk, they can carry more than two people or more goods. jaclaz

Hmmm. Can you teach an old new dog new tricks? And now, for NOapparent reason a lolcatdog : Welcome new member, DejaVu Larry! jaclaz

Good that the switching now works, at the cost of a few Mbytes . Further good news are that I LIED technically that area is not really-really inaccessible, it is possible to use it as a logical volume inside extended that will be accessible ONLY when the disk is connected through the 512 bytes/sector interface, what do you think of this possible added feature? Would it make sense to have that area usable (but only on 512 byte/sector interface)? That "elevated" not found must be a leftover... The issue is here: Try changing it to a simpler: I added the /elevated and the %1 for some debugging version, but now there is no need for them now that things seem to work the way they should.. I must remember to change this (if it works) also in the "simplified" version I am putting together... Right now the Switcher - no matter what - removes the drive letter that Windows assigned (if any) automatically, whilst in practice there are cases where this removing the drive letter and re-assigning it is not needed, I hope to make it so it doesn't unless it is actually *needed*. jaclaz

Good. The LP or "green" drives are somewhat between a 7200.11 and a 7200.11 ES (or maybe even halfway with 7200.12), we have very little info about them, here: http://www.msfn.org/board/topic/150475-st2000dl003-seagate-barracuda-lp-green-2000gb-suddenly-ceases/ Are you trying with: board connected board fully disconnected head contacts insulated motor contacts insulated ? jaclaz

Yep. This: obviously puts an end on this approach, because one would need to NOT run the batch from the FAT12 partition, even if instead of a tool that locks all volumes on the physicaldrive one would lock the single volume matter would not change because - right or wrong as it may be - the Windows 8, since it fails to see the second NTFS as volume, it considers that address as part of the FAT12 partition, so we really need to lock that FAT12 volume. We have to abandon the idea of the overlapping partitions. Find attached a new version of the files mkprilog and mkdualdisk, you need to use this version and recreate the partitioning again from scratch, these will make not the two partitions overlapping, and the NTFS volume should be found also on the 4kb interface on Windows 8.1. Once you have the new partitions formatted, the SwitcherNG should work normally, also on Windows 8.1, on both 512 and 4 kb. In a couple of days I should be able to provide a simplified (hopefully better) version of the Switcher.cmd, but as said in the meantime you could experiment with the SwitcherNG on this non-overlapping partition scheme. jaclaz mkprilog007.zip

Hmmm. Maybe in this unrelated thread, starting form here: http://www.msfn.org/board/topic/173482-can-windows-xp-pro-x86-safely-trim-an-ssd/?p=1094527 you can get a possible solution, from what you write it sounds like the disk is not "clean" nor has "valid" (as recognized by Windows Setup) partitions, as an example this is possible if there is a partition covering the whole (or most of) the disk using a partition ID that Windows does not recognize, let's say a 0x83. jaclaz

Well, it is worth EXACTLY 0. The reported message "it's not a valid win32 app" plainly means that the PE executable will have as either "Major Operating System Version" or "Minor Operating System Version" (or both) something "bigger" than what the XP will report to it, and the same will apply to: Major and Minor Image Version and to Major an Minor Subsystem Version. To be more exact, the XP CHKDSK.EXE will have 5/1, whilst the 7 CHKDSK.EXE will have 6/1. In any case, even if you edit those correctly, you will likely have a whole bunch of missing entry points in n .dll's, some of which may rely on more dll's with missing entry points .... So, the CHKDSK.EXE from 7 will NOT run under XP , but NOT because of "it's not a valid win32 app"... The differences between a 7 and a 8/8.x may be much smaller, still we are talking here of running a tool that can easily bore BIG HOLES on a filesystem for NO meaningful reason whatsoever, as there are as mentioned earlier a couple easy, quick workarounds to limit the memory used. jaclaz

Can you not use Win8PE_SE: http://www.msfn.org/board/topic/161226-win8pe-se/ (or otherwise check the .scripts it uses for Ex7ForW8 and replicate their behaviour on your build)? jaclaz

The kernelEx is not AFAIK a wrapper: http://www.msfn.org/board/topic/149233-kernelex-for-win2000/ KernelEx is intended to replace some "main" .dll's on the system, while both the "old cigarette" and the blackwingcat's "KDW" are intended to "stay local" on the specific program/game/whatever directory. Hard to say how the KernelEx will interact with the one or the other wrapper, in theory there should be no issues, in the sense that IF there are issues with KernelEx, they will be independent from the wrapper(s). jaclaz

Basically it means that IF someone physically enters the room where your PC is AND he/she logs in with a valid login/password THEN he/she might be able to get full control of the machine. These kind of vulnerabilities make no sense[1], meaning that IF someone can put his/her hands physically on your machine there are tens of ways he/she can get full control of it, including by-passing or cracking login password, and what not. Now if you leave your home front door open and have on it a sign to the effect of "Please come in and feel free to use my PC, login is "Admin" and password is "password", THEN it is possible that the "guest" will use one of these vulnerabilities, though it is very unlikely because as said there are tens possible (and actually proved/working) ways to get full privileges. The issue - generally speaking - revolves around the differences between "vulnerability", "risk", "threat" and "probability" and they are interconnected. As I see the matter: A vulnerability is something that in theory can be done.A risk is something that in theory and in practice can be done and that has a given (low) probability of being done.A threat is something that in theory and in practice can be done and that has a given (high) probability of being done. Let's use an example in another field, let's start within your home, specifically your front door lock. Your front door lock is vulnerable, as it can in theory be opened in several ways.There is a risk of the door lock to be opened, as there are several documented ways to open it, let's say by picking it or bumping it.Bad guys are known to go around opening other people's door locks so there is also a threat. The probabilities of your front door lock being opened, i.e. the "step" between "risk" and "threat" depends on a number of factors, the place where you live, if it is a flat in a combo or a family house, your habits, etc. You can change your front door lock with a high security one that cannot (in theory) be picked nor bumped, this way you have eliminated a vulnerability of the lock, BUT this wont' prevent the burglar from opening it with the key copy that is under your door mat or in the flower vase on the left. As well, nothing prevents the burglar to kick open the door, nor to enter from the windows on the back you left open . You have eliminated a vulnerability or two of the lock, but you have not in anyway reduced the risk or the threat of a burglar entering your home. This does not mean in any way that you should remove the lock from your front door or leave it open on purpose, only that the difference in reducing the risk or nullifying the threat between having a "common" lock and a "high security" one is in practice non existing as a given vulnerability has been patched but there are several other vulnerabilities, actually easier to implement or more probable to be used, that would allow anyway the burglar to enter. As it is common to say, a chain is only as strong as its weakest link, and usually, when it comes to computers, that link is the actual user. Previous discussions: http://www.msfn.org/board/topic/163539-are-ms-updates-for-xp-really-necessary/ http://www.msfn.org/board/topic/171606-xp-os-vulnerabilities-after-april-8-2014/ jaclaz [1] in any "controlled" environment, i.e. they may apply to - say - a PC in an Internet Cafe or in a public Library, but not on the average PC at home or in an office.

I don't know , but maybe this thingy is becoming a mountain out of a molehill . If you check the actual CVE's supposedly "covered" by KB3013455, the first three: CVE-2015-0003 CVE-2015-0057 CVE-2015-0058 are about a LOCAL AUTHENTICATED USER possibly being able to gain elevate privileges. The last two: CVE-2015-0059 CVE-2015-0060 are about being tricked into opening a specially malformed TrueType Font and/or a specially crafted document. ALL FIVE are rated as "Exploitability: Unproven". The first three are not a threat as long as you don't allow local access to your PC, the last two while more preoccupying in theory are very unlike to happen if you use some "common sense" when browsing the Internet. Call me reckless or crazy as much as you want, but personally I will sleep fine tonight (and slept also really fine yesterday and the night before) even if I have not patched these vulnerabilities. jaclaz