jaclaz

Of course NOT! I just want to say one word to you. Just one word. (actually two ): http://www.imdb.com/title/tt0061722/quotes?item=qt0282091 jaclaz

Basically - if I get it right - the PC181512 had no issue in switching from 4kb to 512 but the PC2814096 had issues BOTH when the disk was ALREADY (set on PC2XP) to 4096 and when attempting to switch it from 512 to 4kb? NO, please DON'T. We have right now a disk that works nicely under XP on both machines (and with both geometries) BUT that seemingly doesn't on only one machine and only on one geometry. Quick recap of available machines/OS/Connections: PC1XP512 Primary machine Windows XP 32 bit with eSATA connection PC1XP4096 Primary Machine Windows XP 32 bit with USB connection PC181512 Primary machine Windows 8.1 64 bit with eSATA connection PC1814096 Primary machine Windows 8.1 64 bit with USB connection PC2XP4096 Secondary machine Windows XP 32 bit USB connection PC2814096 Secondary machine Windows 8.1 32 bit USB connection Now we have the disk "as is" (and the switcher.cmd) tested on:: PC1XP512 OK PC1XP4096 OK PC181512 OK PC1814096 Missing data PC2XP4096 OK PC2814096 NOT OK Can you fill the "gap" before anything else? Since the PC181512 is OK, it is probable that there is an issue in the switcher.cmd, I am in the process of re-writing it from scratch at the light of the previous reports, inverting/simplifying the detection (and drive letter assignment) logic, but it would be useful to have the data from PC1814096 (or have I missed it? ) jaclaz

Good. Just for the record, in case someone is in need of parsing XML from batch, this little thingy here: http://www.911cd.net/forums//index.php?s=&showtopic=23408&view=findpost&p=159829 works nicely. jaclaz

Being more optimistic , I would try with another (surely working) PSU, over the years I have seen every kind of issues that in the end resulted being connected with a dying/weak PSU. jaclaz

I doubt I will be ever able to "convince" you about the meaning of that article, however these may help: http://www.thewindowsclub.com/system-reserved-partition-windows https://technet.microsoft.com/en-us/magazine/gg441289.aspx www.sevenforums.com/installation-setup/14858-install-without-100mb-partition-new-drive.html Once you have SELECTed a disk in Diskpart and CLEANed it, it is clean (i.e. there are NO partitions on the disk, even IF one or more were on it before) and you can manually create new one (s) from scratch. But I believe that the point is more about the actual when/how you access the command prompt and Diskpart, what has been posted is about pressing Shift+F10 in the early part of the booting. jaclaz

Generally speaking, most windows files part of the setup are cab compressed so that your "amdbusdr.sy_" is nothing but the CAB compressed version of "amdbusdr.sys" so you can try expanding it with EXPAND.EXE, but usually the windows setup (and related tools) can understand this and automatically use either of the compressed or plain version, it is well possible that *something* is wrong in the install/method poweriso uses and once you will have expanded that file, you will get other similar errors for other files. However if this is specific to poweriso, try asking your question to the makers of the software: http://www.poweriso.com/ If it is a "how do I install Windows from USB", then you can get all you need here: http://www.msfn.org/board/forum/157-install-windows-from-usb/ Several different programs and methods to choose from... Or you can use Rufus: https://rufus.akeo.ie/?locale=en_US jaclaz

And still Diskpart works nicely from the windows 7 setup disk as I (and the article you referenced) tried to tell you. If you prefer the "default" Setup of Vista will NOT create that start partition, whilst the "default" Setup of Windows 7 will, BUT BOTH the diskpart in Vista setup AND the diskpart in Windows 7 (BOTH accessed through a command prompt obtained by pressing Shift + F10) will NOT create it automagically AND BOTH will allow you to create a single partition on the SSD. jaclaz

I don't think so. I'm talking about this: https://technet.microsoft.com/en-us/magazine/gg441289.aspx Yep , where it is EXPLICITLY mentioned that: To repeat myself, the "Windows setup program": is a form of WinPE you can use diskpart in it alright jaclaz

Well, still the "dos box" is not really dos, as normally the command processor used in it will be CMD.EXE and NOT COMMAND.COM. to be picky it is a "windows command prompt" or "windows command line". But there is not really-really a *need* for uniextract if all you have to do is to deal with .docx, which are a rather plain set of PKZIP compatible zip files and all you have to do is to search for text inside them. I believe you are wanting something more like zzfind: http://stahlworks.com/dev/index.php?tool=zzfind Apart the above, if you are allowed to use some TEMP space, I see no issues in plainly unzipping with your preferred tool the docx to a named folder and look through the files in it, what may create an issue - depending on the actual specific goal - would be to "manage" the data in batch as the .docx is basically an assembly of XML files, and the XML is - because of the "<" and ">" known troublemakers when parsed in batch, it is possible that you may find useful/more practical something *like*: http://docx2txt.sourceforge.net/ or even get a Windows port of Sed, gzip is pipable fine, and in case, you may do with zippipe (a lesser known little tool, but working nicely in my experience): https://jcarlossaez1.wordpress.com/2005/10/21/on-the-fly-compressionuncompression-is-easy-on-unix-but-also-on-windows/ jaclaz

Sure it would not install (or at least have issues with the device), the "own extra partition" would have been Active and with partition ID 27 (of which Windows 2K, as well as XP know nothing). The idea here is to connect the SSD to a normally working 7 machine and use 7 to create the partition (either through Disk Manager or diskpart) but of course there are no issues whatsoever to create the partition directly on a XP, only this is not possible using the built-in Disk Manager or diskpart that are set to respect cylinder/head boundaries. It is possible that when you used the repair disk you somehow managed to attempt creating a 7 bootable disk, AFAICR the diskpart in WinPE (which is what the "repair disk" runs) works "normally". There are tens of third party tools, including many freeware or Open Source ones capable of creating a "Mb aligned" partition running in XP, or if needed even a hex/disk editor could be used to create one manually. jaclaz

Yep, good , but if you take some time reading around you will see how the almost unanimous opinions around are that the issues are about the attempt (by MS) to force the use of Metro and Apps INSTEAD of plain desktop (and start menu, etc.) and with the forcing of ugly, simplified graphics. The development of tools like StartisBack were originated by this attempt. The original 8.0 was essentially NCI only. The newish 8.1 has a "new" (sucking BTW) Start menu. Of course your approach of a touch enabled device on the field and of a more traditional keyboard/mouse driven in the office makes a lot of sense, and JFYI, being professionally in the same field of building/construction, I adopted it in 1993 or 1994 i.e. now more than 20 years ago: http://www.msfn.org/board/topic/154882-windows-8-first-impressions/?p=989163 http://www.msfn.org/board/topic/155290-windows-8-deeper-impressions/page-169#entry1055477 About Excel (or other computer calculation software) I am a little bit more cautious, in the sense that the limit with computers is the GIGO paradigm: http://en.wikipedia.org/wiki/Garbage_in,_garbage_out over the years I have seen too many people committing or being unable to detect (by using "common sense" or "experience" or by jolting down a quick handwritten calculation on the back of a towel during lunchtime) gross errors coming out because the input data was wrong to "trust" anything "machine produced" just because it was "machine produced" (though of course the cause of the error is anyway on the human part). Since you are a structural engineer, you can well understand how some doubts on the approach may be raised when (as it happened to me) a freshly graduated (and rest assured, smart, capable and nice) engineer comes to you after having made - say - a SAP2000 based software calculation for a 1 mt tall, 30 cm thick, reinforced concrete wall, stating that a Ø26 mm every 5 cm is needed on both sides... jaclaz

Found answers: http://www.zdnet.com/article/how-much-does-microsoft-make-from-pc-makers-with-windows-8-1/ http://www.windowscentral.com/windows-81-bing-costs-10-oems-10-configuration-discount And it seems like the only limitation is that the OEM has to set Bing as default search engine, though the user is free to change it to - say - let me think what would be a suitable search engine - Google.... That would be IMHO interesting data, the average amount of time (which I believe could be expressed in minutes ) that the customer spends on Bing before switching to another search engine. jaclaz

Well, on the other hand, this is a way to have an unified experience, you get the same window size that you would get on a 2" smartphone display .... jaclaz

Hmmm. not from actual "dos", but in a Windows command prompt, yes. http://legroom.net/software/uniextract Or open the (say) English.ini: the syntax has not any switches: Uniextract.exe [filename [destination]] I.e. you simply run either: Uniextract.exe c:\1\example.zip c:\test or Uniextract.exe c:\1\example.zip /sub BUT: Basically Uniextract is a GUI wrapper around a number of command line tools. What it does is to (hopefully) identify (via Trid, which is a command line tool) the format of the installer and run the (hopefully) appropriate - btw usually also command line - unpacker/decompressor. The very nature of Uniextract makes it not very suitable for batch usage because in a number of occasions for a "same" installer more than one method/tool is available, so if you have a bunch of files it may be better to "bypass" uniextract and run directly the "underlying" tool. jaclaz

Yes, the "Initial" drive letter assignment to the FAT partition needs in some cases to be done manually, using Disk Manager, because it is possible that - like it just happened to you - there is a conflict with a network drive (or some other drive, let's say a virtual disk or the like). I don't think this can be avoided, since the "automatic" assignment of drive letters happens right at the moment the disk is connected and the mount manager performs it immediately, seemingly without checking for these "non-fully-integrated" volumes/drives. Among others, this is one reason why the idea is to have the batch only run from the specific "dual mode" FAT volume (which allows for a better portability, i.e. the tool is "self-contained", but forces us to use the "queer" partitioning scheme, so that there is no need to change anything in the MBR) as you have to access properly the FAT partition in order to run the switcher.cmd, and since both the batch and the two alternative bootsectors for the NTFS partition are on the same FAT volume (that is on the same disk as the NTFS volume) there are little risks to deploy the wrong bootsector (from another "dual mode" disk) or to have not the "right" bootsectors available. To be fair, one could even think to create the "other" bootsector for the NTFS volume "on the fly", but since after all it is a matter of just 2 files 4096 bytes each it is not an issue with "occupied" space, and I would probably need more tools, like hexalter and dumphex added to the volume. A possible evolution could be that of creating a backup/copy of those two sectors in an unmapped area of the disk, like - say - sectors LBA 47-54 and 55-62 so that - even if they are deleted by mistake from the FAT volume, they can be recovered anyway ... jaclaz

Or - more probably - you needed to vent some of your repressed anger and took us as target joining the board just for this reason... Obviously creating a spreadsheet in a computer and then copy it by hand instead of printing it makes no sense whatever , but while the electronic spreadsheet invention (let's say Lotus123) was a BIG leap forward and the advent of GUI ones, (let's say Borland Quattro and Excel) was another step in progress, I fail to see much meaningful difference between - still say - Excel 97 (yes that was 16 bit) and Excel 2000 and between Excel 2000 and later versions, it's a looong time that spreadsheet programs are "mature" and no new useful/practical feature is added to them, the changes having been lately (like in the last ten years ) only cosmetic. As a matter of fact the change to the ribbon interface in Office 2007 is in my opinion much more a worsening rather than a bettering. Anyway, when an Excel Spreadsheet done on Windows 10 with - say - Office 2013 or Office 365 will be "better" or "more accurate" or "created in less time" than the same spreadsheet done on a plainer XP, Vista or 7 with Excel 2003, then we will have another step forward... jaclaz

Good. ... and this probably explains why the good MS guys by default assign Network drives to drive letter Z: : http://support.microsoft.com/kb/308582/en-us Try the attached new version 0.07 this should be able to take care of the Network drive(s) also. I am as always fighting between making the batch too or too little verbose . If this version works on PC1 and PC2 machines under XP, next step would be to see how it behaves under 8.1 jaclaz Switcher007.zip

Good. It is strange, the mountvol and reg.exe logs indicate that the second NTFS partition is mounted as drive letter E: There is probably some kind of "conflict" with your drive E:, which is if I remember right a network connected drive. It is possible that *somehow* an earlier run of the batch (or whatever) has created a kind of "sticky" drive letter in the Registry (or whatever). Try the following: remove/disconnect the USB disk open regedit and navigate to HKLM\SYSTEM\MountedDevices delete the entries that have a binary value starting with 4455414C, there should be 4 of them, as per regexe.log: change the drive letter connected to your network drive (temporarily) to Z: reconnect the disk and re-run the batch In the meantime I will see if I can find a simple way to detect network drive letters in use... jaclaz P.S.: Please also run this command: wmic path win32_logicaldisk get name, drivetype

Hmmm. Try the attached switcherdh.cmd, I rechecked it and added some more verbose output. I could find no issues with your edits (exception made for a missing double quote, but that would have only affected the :remount part). The current issue is *somewhere* in the part that (:mountcheck and/or :notmounted) attempts to detect/find the drive letter/VolumeID for the second partition, on the PC2XP4096 there must be some "remains" in the Registry mounted devices (or however something that I seemingly cannot reproduce/imagine) that "tricks" the batch, making it assign an empty value to the SecondVolumeID variable. Can you try again the attached on the PC2XP4096? Please additionally run a: MOUNTVOL>mountvol.logand a REG QUERY HKLM\SYSTEM\MountedDevices>regexe.logand attach the two logs, besides the output of the switcherdh.cmd jaclaz Switcherdh.zip

Sorry, "somehow" I either mistyped or the board code tags did their "magic" There must be no spaces between "SET SecondDriveLetter" and the "=" (and of course no spaces after it), and the same applies to the other line forSecondVolumeId, the scope of the lines is to undefine the two variables... Otherwise the batch seems correct, it may be advisable to rephrase "Disk is mounted as" changing it to something like "Disk is connected as" or "Disk has an interface read as" or the like, whatever you believe being more clear or less confusing. However that is the message that the line should convey, the Disk (the whole thing) is "seen" by windows as having that sector size. jaclaz

Mostly pointless post , but a good way to let Dave-H notice I have edited (adding things to do), my previous post and that I received correctly the info about the machines. jaclaz

That is something to be understood, most probably *something* doesn't proceed as expected in the batch.While you are editing the switcher.cmd, make also the following edit, find the label :mountcheckand add right after it a couple lines, so that it becomes: :mountcheckSET SecondDriveLetter=SET SecondVolumeID=this way the second drive letter is re-determined each time, which should avoid that false detection. And it is possible that this: is the actual reason of the more generic issue, as the diskpart command issued "assign" equates to "assign first drive letter available", and it is entirely possible that for what diskpart knows first available letter is E: on that machine... So, in the batch, edit here: Changing it to: And the same could be done - to be on the safe side - to the previous diskpart "remove" command, changing: to jaclaz

.prf or .msp file mis-configured? http://support.microsoft.com/kb/2590591/en-US jaclaz

The "traditional" way (Vista or 7) is to attempt installing the update in Safe Mode or clean restart: http://windows.microsoft.com/en-us/windows/windows-update-error-80070020 cannot say whether this may work in 8.1 as it did on earlier systems. Also, knowing the specific update may make a difference, as an example KB2919355 has been in the past a known issue, see: http://www.softpedia.com/blog/How-to-Fix-80070020-80073712-and-0x800f081f-Errors-on-Windows-8-1-Update-437334.shtml jaclaz

Good , a little step in the right direction.The issue is here (within switcher.cmd): The batch detects the NTFS volume as drive H:, checks it's current bootsector, recognizing it as the 512 bytes one <- till now everything seems finethen it attempts to remove the drive and re-assign to it a drive letter <- this is provided as in some cases it is possible that the volume is seen as "RAW" (if you right click on the volume in explorer and select properties) THIS IS THE PART THAT FAILSit continues nonetheless, but since for *some reasons* the drive letter H: was not re-assigned to it, it FAILS (and FAILS BIG) at deploying the bootsector (the "missing file" in the dsfi message is the actual \\.\H: volume)#2 above is done through a set of diskpart scripts, that basically amount to: select disk %Disk#%list volumeexit select Volume %Volume#%removeexit select Volume %Volume#%assignexitThe value of %Disk#% is surely correct as it is assigned by a "direct find" in WMI, and it amounts to "1", coming from the intitial "\\.\PHYSICALDRIVE1", the value of %Volume#% may instead well be wrongly assigned, as it comes from parsing the diskpart output of the first diskpart script .Try editing the switcher.cmd in the :doremount subroutine, this part: SET ThisDriveLetter=%SecondDriveLetter::=%FOR /F "tokens=1,2,3 delims= " %%A IN ('MORE +!More_offset! %~dpnx0^|diskpart.exe^|FIND /v /i "DISKPART"') DO (IF "%%C"=="%ThisDriveLetter%" SET Volume#=%%B)IF NOT DEFINED Volume# GOTO :error2 so that it becomes: SET ThisDriveLetter=%SecondDriveLetter::=%ECHO This is :doremountMORE +!More_offset! %~dpnx0|diskpart.exe|FIND /v /i "DISKPARTFOR /F "tokens=1,2,3 delims= " %%A IN ('MORE +!More_offset! %~dpnx0^|diskpart.exe^|FIND /v /i "DISKPART"') DO (IF "%%C"=="%ThisDriveLetter%" SET Volume#=%%B)SET Volume#PAUSEIF NOT DEFINED Volume# GOTO :error2 and post the output when the batch pauses. Can you also please: take note of this: If we don't find a common, easy enough, way to identify which is which we risk a misunderstanding.jaclaz