jaclaz

No need to be confused , please read the (from the Amazon link): Easy plug-and-play installation into any 32-bit PCMCIA Type II slot; hot-swapping capability as "CardBus" and notice the golden "grounding strip" in the photo. jaclaz

Actually it means MUCH MORE than "99.9% uptime", it means 99.99% RECORDED uptime in the LAST 30 years (or more), i.e. a recorded, verified extremely high reliability over an extremely long period. , not foolish at all. As I like to remember people in my work field (construction), we know for sure that a Roman arch or tunnel can stand 2000 (two thousand) years substantially unscathed after having gone through numberless earthquakes, thunderstorms, hot/cold cycles, floods and *what not* while bridges and buildings built in the 19th century and even in the 20th century need to be rebuilt or heavily repaired after as low as thirty to fifty years since construction, there might be REASONS for this. jaclaz

Maybe it was a CardBUS (please read as PCI) and not a PCMCIA (please read as ISA), and yes it is a confusing matter, see (JFYI): http://www.msfn.org/board/topic/141776-modifying-a-really-old-dell-laptop/ http://www.msfn.org/board/topic/141776-modifying-a-really-old-dell-laptop/?do=findComment&comment=907932 Anyway, either CardBus or PCMCIA it doesn't matter, it was an added peace of hardware. jaclaz

Well, to me the ones that made the CBS.log so verbose AND did not provide a senceful way to parse it for the actual useful info seem a lot like belonging to the "bad" kind of MS engineers (but it can be much worse than that). If you think about it it would make a lot of sense, the "good" ones were busy writing kernel level software and let trivial things such as simply logging the actions of a simple verification program in userland to some "kids" (with no offence intended for the "kids", here it is meant only as "less experienced" or "less practical"), the level of (mostly unneeded) details in the logging seems to me like what a student would do in order to show his/her teacher how accurate his/her programming is (and - to make a comparison for the old people - traditionally "mixing" standard output with standard error is the typical "newbie" mistake). Yes , but maybe we are looking at it too much as black/white. Like shades of gray, it depends on the amount of black and amount of white, and there is not a definite line to separate those. jaclaz

Well, it would need some "miracle" or "magic". Strange. Was it maybe a sort of add on card ? Anyway the USB 1.0/1.1 and 2.0 were much more similar between them (as an example there have been a lot of motherboards that had USB 2.0 ports but had BIOS that only supported 1.0/1.1 speeds, so that DOS would have slow speed whilst a Windows - with the appropriate driver installed - would have faster ones), but USB 3.x is an altogether different "beast". A USB 3.0 port is normally connected to an internal PCIe bus (because a PCI has simply not enough bandwidth/speed), see as an example: http://usb3pcicard.com/pci-and-pci-express-pcie-usb-3-0-cards/ jaclaz

Well, in a perfect world someone would write a SFC replacement with a (optional) .ini file (or similar) listing inclusions and exclusions, the user could manually edit the lists, then once verified that everything in the list is OK, hash/checksum/sign it to avoid manipulation by malware. After all it doesn't seem to me like "rocket science" at least conceptually: 1) fill a list with (say) filenames, sizes, versions and hash 2) verify that all files in the list match 3) if not attempt restoring the original 4) if restore fails log the error (possibly in a less verbose/convoluted manner than what a CBS.log now looks like) 5) loop to #2 for next file But - from a purely logical standpoint - there is some flaw in your reasoning, you are trusting a tool written by the same guys that are not capable to provide updates correctly. Anyway a quick peek at the CBS (now not so quick given the senseless complexity of those logs) would assure you that the issue was with the remove Search thing., but if there are two or three exceptions it wouldn't be too hard to write a simple batch (or similar script) veryfying that the errors are only the known ones, let's say: Error #1 Windows Search removed Error #2 Stupid usbport.inf.resources in Convenience Rollup A (much less than optimal) way is to simply run (as suggested by MS) a findstr /c:"[SR]" %windir%\logs\cbs\cbs.log >sfcdetails.txt This: findstr /c:"[SR]" %windir%\logs\cbs\cbs.log|FIND /i "Repair"|FIND /V /i "Verify" >sfcdetails.txt should be slightly better. As a side note (and JFYI) there exist a couple nice tools that make (in my limited experience) a good work in analyzing the CBS.log: http://batchapp.webs.com/miscellaneous.htm and SFCFIX: https://www.sysnative.com/niemiro/apps/SFCFix.exe though this latter (if I recall correctly) might not be suitable as ti attempts to fix the corruptions anyway (surely it saved my day a few times however) jaclaz

monroe, a Lenovo T42 has ONLY USB 2.0 ports AFAIK (this is HARDWARE): https://support.lenovo.com/us/en/documents/pd008824 WHICH model do you have? A T42? then NO driver will EVER exist capable of transforming a USB 2.0 port to a USB 3.0 one. ANOTHER model? WHICH one then? jaclaz

Oww, come on , it is not the end of the world, when you run SFC you know that you will have this single error and that it is a false one, "harmless" as abbodi1406 called it. Sure it is "sloppy work" but "sloppy work with no remarkable adverse effects in practice", there have been over the years tens of much more serious issues including the "abnormal time" it takes Windows 7 to check for updates and install them that actually has some "serious impact" in people's workflow. And even IF update works (when it used to) it may take hours to download all the updates (particularly on a slow connection) think at all the hours were wasted by people installing 7 because of the STUPID new idea of not releasing periodical Service Packs, JFYI: The image (via Wayback Machine) : jaclaz

And ... just in case she's watching : jaclaz

@risk_reversal I would be curious to understand how this doubt came to you, I mean, did you experience corruption when using SATA II? Or did you read some reports of data corruption happening on that controller in SATA II or SATA III mode? BUT if you are using IDE mode in the BIOS, you are not using SATA at all (i.e. the jumper of the hard disk won't make a change) the disk will be accessed in IDE mode (i.e. THEORETICALLY 133 mb/s as opposed ot the SATA I 150 mb/s or SATA II 300 mb/s) anyway. As a side note and general advice, with SATA it has come back to life the advice Jerry Pournelle gave in the good ol' times of SCSI, in case of issues it is ALWAYS the cable (JFYI): http://www.jerrypournelle.com/chaosreports/Recommended.html#Storage http://www.msfn.org/board/topic/163189-hard-drive-controller-errors-abound-atapi-event-11/ jaclaz

Nice find . Now, for no apparent reason : https://en.wikipedia.org/wiki/Ouroboros jaclaz

Yep , but you used the (common) CLS and re-drawing whole screen, and you are actually giving the user a totally false "estimation" of the time left, you are actually continuously showing the current time, if the "real" program actually takes 5 minutes to execute and terminate, you will have the user receive roughly 5*60/2=150 false informations It would IMHO be more logical to time once the actual time it takes on an "average" machine, add to it (say) a 20% increase, so that the user will have something like: Time is now 11.47.16 Starting program ... Expected time 360 seconds Executed in 305 seconds. <-line that continuously updates "Elapsed time" Time is now 11.50.21 And will have additionally the "good feeling" that his/her machine is faster than expected (still false, BTW). Find attached a couple "almost finished" batches showing the "time elapsed". First one uses a time format, the second uses "plain" seconds (and is thus simplified). The posted ones use WMIC instead of TASKLIST as this (strangely) avoids the flashing (or viceversa strangely TASKLIST induces the flashing of the line). jaclaz time_exe.zip

Side note (and most probably unrelated) but historically the good IPB guys have decided that anything shorter than 4 letters is not worth their precious time/attention[*] (it is years that in the Search facility - even at the time when *somehow* it worked more or less) you could not find posts containing a three letter word (such as "IPB" ) not even double quoting it and the same happened when you searched for "by Author", if the member name was three letters it came out as "a suffusion of yellow". Maybe the "loss" (hopefully temporary) of -X-'s profile is *somehow* connected to this particular stupidity. jaclaz [*] Just like all those trifling things like "customer support", "quality assurance", "continuity in development", "testing before releasing", etc.

Good, I am Italian and I can tell you how writing in ALL CAPS is considered, on this board and everywhere else on the internet as either shouting or extreme lack of politeness. Please do check also Rule #11 http://www.msfn.org/board/guidelines/ Just for your knowledge, however, Hebrew uses a different alphabet and is written from right to left, no possibility to confuse it, and just in case, please do review Rule #7.a, additionally. Kanth you for understanding. jaclaz

Naah, not that much old , it is in the very introduction of that (now officially endorsed ) article: jaclaz

To do what? If the USB driver is not active (one way or the other) an USB disk will NOT be seen (and will error out if booted with a 0x0000007b) and without a suitable driver for the controller *any* Windows 7 or PE 3.x won't ever see the emmc. jaclaz

Why not? IMDISK is normally used in PE's alright but if all you need is to mount a .iso and for *whatever reasons* you don't like IMDISK there are several alternatives, including filedisk and even the good ol' virtual CD control panel by MS could do (for 32 bit). A number of program of this kind are listed here (JFYI): http://reboot.pro/topic/1507-ramdisk-and-filedisk-drivers/ Specifically for IMDISK, you can install it on-the-fly (see FGA #13): http://reboot.pro/topic/15593-faqs-and-how-tos/ or plainly install the driver with SC, *like*: http://reboot.pro/topic/5531-install-and-uninstall-imdisk/?p=43137 (this will work with most of these drivers) jaclaz

It doesn't work this way. If you know HOW to use the needed tool(s) you don't ask about WHICH is/are the needed tool(s). CATCH 22. You need to study and learn a lot about X86 assembly, Windows programming and interfaces, before starting to debug and disassemble successfully executables, and only once you will be familiar with all the mentioned topics, and I mean VERY familiar with all of them, you will be able to start some real reverse engineering, and finally you will be able to actually re-assemble and insert code "arbitrarily" in a pre-made executable. Of course by then you will be familiar with all the "tools of the trade" (and possibly also write/code your own ones). Anyway - usually AFAIK - codecaves are used instead, here is a good start for you: http://www.codeproject.com/Articles/20240/The-Beginners-Guide-to-Codecaves jaclaz

You don't need to "extract" the .iso, you can mount it as a virtual drive with IMDISK or other similar tool/driver. jaclaz

Dybia, that is perfectly "normal". If you INSERT *any* byte ALL jump (or similar) instructions pointing to *any* address after the insert point will need to be re-based/re-calculated. In any case you normally DO NOT insert 00's in an executable, but rather 90's (or NOP's). jaclaz

First is an (ab)use of the PROMPT command (this is "rare" or "advanced"), see: http://ss64.com/nt/prompt.html http://superuser.com/questions/82929/how-to-overwrite-the-same-line-in-command-output-from-batch-file Second is due to expansion of parameter %1 (first parameter) in the CALLed subroutine (this is instead pretty much "common" or "simple"). When the batch CALLs the :to_HHMMShs subroutine as: CALL :to_HHMMShs Delta The "Delta" becomes %1 (and viceversa) so what will be executed will be: SET /A DeltaHH=!DeltahsVal!/360000 SET /A DeltaMM=(!DeltahsVal!-!DeltaHH!*360000)/6000 SET /A DeltaSS=(!DeltahsVal!-!DeltaHH!*360000-!DeltaMM!*6000)/100 SET Deltahs=0!DeltahsVal:~-2! SET DeltaHH=0!DeltaHH! SET DeltaMM=0!DeltaMM! SET DeltaSS=0!DeltaSS! SET Delta=!DeltaHH:~-2!.!DeltaMM:~-2!.!DeltaSS:~-2!,!Deltahs:~-2! jaclaz

But on wednesdays nights? (only when the moon is full, of course) Anyway - not really important since the intended volatility of the tool (and of it's support, ending on 1st October 2016) - what you posted is titled documenation (as opposed to documentation). jaclaz

NONE are "abandoned". ALL are past End of Support. https://blogs.msdn.microsoft.com/windows-embedded/2014/02/17/what-does-the-end-of-support-of-windows-xp-mean-for-windows-embedded/ PosReady 2009 extended support will end on April 9, 2019. jaclaz

no, yes (if the XP is OEM), here: https://allanjsmithie.wordpress.com/2014/05/15/how-to-upgrade-from-xp-to-windows-7-oem/ You might be able to find a legal Windows 7 (or more likely 8) "System Builder" license , but that is not anyway an upgrade, it is a "ful install", see also here: http://www.howtogeek.com/198358/whats-the-difference-between-the-system-builder-and-full-version-editions-of-windows/ and of course the whole matter is a mess/it is clear enough/it is a mess again: http://www.howtogeek.com/197232/microsoft-is-misleading-consumers-with-windows-8.1-system-builder-licensing/ https://www.microsoft.com/OEM/en/licensing/sblicensing/Pages/windows-licensing-for-personal-use.aspx#fbid=yKQtWFuwIG0 It makes no sense to buy a proper 7 or 8/8.1 license if the idea is to upgrade downgrade to Windows 10, simply get a Windows 10 license. jaclaz

What you report is really strange. I could understand if you could not see any folder in drive F: (which could be some misconfiguration related to the card format) or if you couldn't have F: at all, but you can access the top level folder and then inside it you cannot find the actual photos (files) is perplexing. Try the following as a test. 1) on one of the Windows machines that "sees" files inside \db\dcim\100OLYMP copy to the F: drive two files (any small sized .txt file will do), one in \db\dcim\ and one in db\dc\100OLYMP\ folders 2) move the camera to the non-working machine and verify you can (or cannot) see those two files Another thing that you can try is to clean the system from all USB devices (see here): but it applies to different symptoms. jaclaz