jaclaz

If I recall correctly, what I saw around (more prosumer than professional) were: Ulead https://web.archive.org/web/20000815234845/http://www.ulead.com/vs/ Pinnacle https://en.wikipedia.org/wiki/Pinnacle_Systems Pro's largely used (again if I recall correctly) Avid : https://en.wikipedia.org/wiki/Avid_DS https://en.wikipedia.org/wiki/Media_Composer jaclaz

You could also try to install the older update, KB4019276 https://msfn.org/board/topic/177994-tls-1112-and-vista-issue-no-options/ The thread contains also a note about possibly needing (of course if either update is installed) to modify also the contents of Wow6432Node\CRYPTO on x64 machines. Also: https://answers.microsoft.com/en-us/windows/forum/windows_vista-update/updates-not-working-it-has-been-searching-for/92cd6922-17f6-4730-b46b-91a480b95dd3?page=1&messageId=1ef00080-91e9-4ffa-a5a3-92f6ecd69c32 jaclaz

... and sometimes fail at it ... I understand what your question was, but, since noone knows (or won't tell you ) how to use the specific tool you want to use to obtain the specific expected result, I suggested another possible way to obtain the same actual specific expected result. I will use one of my re-known (and lousy ) carpenter's comparisons: I read your request as: "I need to join two pieces of wood, I tried superglue but it didn't work." To which I replied: "You could try using the old school way, nails or screws and vinyl glue, instead. Rest assured that the two pieces of wood will remain joined" jaclaz

Try following this, it is essentially the same set of instructions: https://johnhaller.com/useful-stuff/enable-tls-1.1-and-1.2-on-windows-vista re-assembled in a way that should be easier to follow/replicate, with a simple pre-made .reg to be merged in the Registry and with an additional link to last Firefox version working on Vista (just in case). Then try following this: https://help.hotschedules.com/hc/en-us/articles/360020184072-Enabling-TLS-1-2-on-web-browsers#Firefox jaclaz

On second thought, re-reading the two example diskpart scripts, they are identical, and have the same identical effect, so there is no need to choose a disk size at all. The first part always create a 2048 MB 1st, primary, active, partition with label "Systeme". The second part always creates a 2nd, primary partition with label "Data" with the whole rest of the disk (i.e. variable in function of the size of the disk). jaclaz

Allow me to doubt that any search engine will find any iso "with all the drivers for my SATA laptop", jaclaz

Sure, but the most basic scenario is that OP has to configure 100 (1000 or 10,000) similar machines that all come with one single disk BUT which size can be any of 120 GB, 200 GB, 450 GB, 1 TB and 2 TB. The main possible issue is IMHO - besides and before the case of more than one disk - that the user wrongly chooses the disk capacity. Then, there is no check to whether diskpart sees the disk(s) correctly and/or with the "right" number In cases like this - since (roughly) the capacity of an unpartitioned/unformatted disk can be easily found by diskpart - and adding your correct comment about the possible error about selecting the wrong disk I would go the other way round, first fire up diskpart looking for disks and specifically for disks unpartitioned/unformatted and then give the user only the option to partition/format that disk, automatically calculating the size of the second partition. This said, if the scenario is similar to the above, It might be easier/better/faster/etc. to use a FFU image instead: https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/deploy-windows-using-full-flash-update--ffu https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/wim-vs-ffu-image-file-formats Various tests and considerations on FFU use: http://reboot.pro/topic/22182-capture-and-apply-windows-full-flash-update-ffu-images/ BTW, whilst in the FFU case it is needed, even in the "normal" approach seen above, the diskpart extend command may be used, if size is omittd it will default to "all available size on the right", thus filling the disk to the brim without needing any calculation. Of course it needs to be tested, but very likely partition/format/deploy FFU/extend partition will be faster than partition/format/deploy WIM or take the same time. jaclaz

To be fair, once "in production" the Windows 10 will be installed at a time where only one disk to be partitoned/formatted is connected, but it wouldn't be a bad idea to actually verify the disk sizes and avoid the possible operator error. jaclaz

Thanks , hadn't noticed. Maybe this: https://forums.guru3d.com/threads/ati-registry-tweaking-guide.51433/ jaclaz

Well, this is not at all "surprising". The B166713 folder corresponds to the CX166904.inf that contains the PCI\VEN_1002&DEV_9838 (but not the PCI\VEN_1002&DEV_9839) The B166496 folder corresponds to the CX171234.inf that contains NOT any "Kabini" related HWID. I would say that only files corresponding to a .inf with a provision for "ati2mtag_Kabini_Mobile" have a possibility to work. I am every day more convinced that the issue is with your card being part of the APU/embedded, while "ordinary" drivers are for "self-standing" cards - indirectly - this is confirmed here: https://www.intel.com/content/www/us/en/support/articles/000028808/graphics/graphics-for-8th-generation-intel-processors.html jaclaz

Yep, it is not like you have that many alternatives anywyay. jaclaz

Curioser an curioser. The two drivers have essentially the SAME files (by version AND by size) BUT they are largely different . It makes little sense, it is practically impossible to compile two - even if only slightly - different sources to the same .exe/.dll size and compiling them leaving the same version is more than sloppy, bordering with total crazyness. See the attached. jaclaz Compare.xls

You usually need to assign a drive letter in diskpart: https://www.windowscentral.com/how-clean-and-format-storage-drive-using-diskpart-windows-10 Or you can use (externally) MountVol: https://ss64.com/nt/mountvol.html Since you only have to deal with "normal" volume/partitions on physicaldrives, you won't need anything else, however, and just in case, in this thread it is discussed at length on the various NT devices and DOS ones, besides providing a number of possibly useful tools: http://reboot.pro/topic/19622-vmount/ starting from around here: http://reboot.pro/topic/19622-vmount/?p=214603 jaclaz

Post one or two of the .txt diskpart script. JFYI, later (i.e. once the diskpart scripts/commands are tested and work) it is possible to embed them within the batch. See: https://msfn.org/board/topic/126069-updated-on-feb-27-2011-ordering-messed-drive-letter-batch-file/page/2/?tab=comments#comment-817142 https://msfn.org/board/topic/126069-updated-on-feb-27-2011-ordering-messed-drive-letter-batch-file/page/2/?tab=comments#comment-817388 You need "better" control of the input, if the user by mistake inputs "strange" characters there may be issues, though it is possible to better validate set /p input, In windows post-XP there is (in case) the choice command which accepts input without needing the [ENTER], maybe it would be more suited than set /p (as it has - besides input validation - also a timeout and a default provision): https://ss64.com/nt/choice.html jaclaz P,S, : ONLY for the fun of it, this is how I would have written your batch (mind you everyone has his/her own "style", not necessarily one is better than the other): @ECHO OFF SETLOCAL :debut CLS SET my_120GB=1 120 GB c:/Project/120.txt SET my_200GB=2 200 GB x:/diskpart/200.txt SET my_450GB=3 450 GB x:/diskpart/450.txt SET my_1000GB=4 1000 GB x:/diskpart/1000.txt SET my_2000GB=5 2000 GB x:/diskpart/2000.txt ECHO *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* ECHO "DISK CAPACITY AVAILABLE" ECHO *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* ECHO. ECHO 1^) 120 GB ECHO 2^) 200 GB ECHO 3^) 450 GB ECHO 4^) 1000 GB ECHO 5^) 2000 GB ECHO. ECHO *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* Choice /T 60 /D 1 /C 12345 /M "Choose your disk:" ECHO *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* CALL :MyChoice %Errorlevel% ECHO DONE. PAUSE :fin GOTO :EOF :MyChoice FOR /F "tokens=2,3,4 delims= " %%A IN ('SET my_ ^|FIND "GB=%1"') DO ( ECHO. ECHO "you have chosen: %%A %%B" ECHO diskpart /s %%C ) GOTO :EOF

But does it BSOD "by itself" or only when you attempt changing resolution? Back to past post: Or it does BSOD on reboot? Or both? jaclaz

What happens if you try (after having completely uninstalled the Catalyst software) to reinstall only the driver via the .inf file? jaclaz

Well, my friend, I am wrong and ignorant, no real need to provide your academic qualifications. jaclaz

Ok, for the record that reference is "wrong" in the sense that it applies to a "simple" XP system (not one that has been made in dual boot with a later (Vista, 7 or 8/8.1) NT system). THIS: http://www.multibooters.co.uk/multiboot.html (scroll down until you find "Dual-Boot Sequence") is more or less what happens in these cases (and what is more or less happening to you from your report). Point is that BOOTMGR (not BOOTMGR.EXE) is invoked by the PBR code and can read directly the BOOT.INI (needing not the NTLDR) limited to the Windows XP (NT/2K) entries. So what you are having now is: BIOS->MBR->Active Partition->PBR->BOOTMGR->BOOT.INI->Windows XP or (but I seriously doubt it): BIOS->MBR->Active Partition->PBR->BOOTMGR->NTLDR(+NTDETECT.COM)->BOOT.INI->Windows XP The above (even if it works) is technically "wrong", as what you should have should be: BIOS->MBR->Active Partition->PBR->NTLDR(+NTDETECT.COM)->BOOT.INI->Windows XP to have a "kosher" XP only system. If you wrote with BootIce or with any other tool a "NT60" PBR code invoking BOOTMGR, rest assured that it invokes BOOTMGR. The reason why the "NT52" PBR code (invoking NTLDR) doesn't work possibly (but it has to be checked) may depend from the fact that you copied NTLDR and NTDETECT.COM on an already filled up volume and the files were written to a too high LBA address OR it could be an issue, as said with geometry (either in the MBR partition table or in the PBR data, tools that can write the PBR code, such as BootIce or bootsect.exe, replace the code leaving the PBR data as it was and the NT/2K/XP bootsector code is sensible to these CHS geometry mismatches, to the point that there are patches for them). jaclaz

Or maybe someone knows but he/she isn't going to tell. To be picky, it seems to me like you are losing the final scope by focusing on the means. There is no law stating that a restore point needs to be made by task scheduler. You could have a script (batch/vbs/whatever) run at startup every time that checks if: 1) the day of the month is 1,4,7, etc (or 2,6,10, etc,) 2) there isn't a restore point already made today and if both conditions are met starts a manual restore point backup. jaclaz

Well, having a reply in a time between 2 and 10 days is not so uncommon on other forums, here we are usually exceptionally more responsive, and personally, even if I started a few hours late, I am moving fast . jaclaz

1) the "Forced3001" uses the CX166904.inf and a directory containing the files B166713. The CX166904.inf DOES NOT contain a provision for your hardware. 2) the "ATI3005" uses the CX178340.inf and a directory containing the files B175198. The CX178340.inf DOES CONTAIN a provision for your hardware: "%AMD9839.1%" = ati2mtag_Kabini_Mobile, PCI\VEN_1002&DEV_9839 ... AMD9839.1 = "AMD Radeon HD 8180" Actual files in - respectively - B166713 and B175198 are largely the same. So, your best bet/first attempt should be to install the "ATI3005" as is, it should install without issues. Try first to install it via the CX178340.msi, at least in theory it should work and be the "intended method" by the manufacturer (short of installing the whole bloated thingy with control panel and what not) jaclaz

Yep, and reviewing past posts on this thread it is not like we did a much more clear work, the thread as usual goes like: try this, I tried it but it was no better than the other, no, not that one the other one, that I tested with the modified .inf, but not with that modified .inf, the other one, that once booted and then I couldn't reproduce, possibly because that time I was using another driver, etc. Let's make some order, we have 3 (three) 2 (two) possible candidates: 1) https://driverpack.io/it/hwids/PCI\VEN_1002%26DEV_9834?os=windows-xp-x86 Filename: AMD-FORCED-Catalyst-5x86-drp.zip, Size 32 MB from now on referenced as "Forced3001" 2) https://archive.org/details/icafe-winxp-9.00.300.3010-beta1-br294594-sep24 Filename: icafe-winxp-9.00.300.3010-beta1-br294594-sep24.exe, Size 58 MB, from now on referenced as "iCafe3010" 32) http://web.archive.org/web/20150525015957/http://www2.ati.com/drivers/windows-xp-amd-catalyst-9.00.300.3005-dec9.exe Filename: windows-xp-amd-catalyst-9.00.300.3005-dec9.exe, Size 192 MB, from now on "ATI3005" Can we agree on the above? jaclaz P.S. the "icaf3010" driver has not any provision for any "Kabini" processor/card, so it is out of the list.

Well just in case Wayback Machine preserved it as well: https://web.archive.org/web/20181007202929/https://medium.com/@dvorak/5g-got-me-fired-ce407e584c4a jaclaz

Wouldn't these do? https://download.cnet.com/ATI-MOBILITY-RADEON-X300/3000-2108_4-131387.html Otherwise, the most you can have is VBEMP: https://bearwindows.zcm.com.au/vbemp.htm jaclaz

For the record, the flashing cursor (top left, white on black) is often connected to an issue between CHS and LBA entries in the MBR partition table (and/or in the PBR geometry data). This often happens when a not entirely "proper" tool i used to do the partitioning or (this used to be a common case some years ago) when you transplant a disk from one PC to another (particularly laptops there were a lot of BIOSes around that used 240 heads geometry instead of 255). BUT: WHY? Was it really-really BOOTMGR.EXE or more simply BOOTMGR? WHO told you that it was unneeded? In some dual boot installs the BOOTMGR (not the BOOTMGR.EXE) is the actual loader for NT (XP) systems (and the PBR code is the "60" one). There may be several reasons why now you cannot boot the NTLDR (even if you changed the PBR to "52"), one could be the actual placing of the files (NTLDR and NTDETECT.COM) in the volume. You can trouble shoot the issue using grub4dos. Best would be if you have a (spare) USB stick and you can boot to a grub4dos on it, grub4dos can be run just fine from MS-DOS (as grub.exe), I am not so sure about it running under IBM PC-DOS 7 , it should work but it has not been tested as extensively as in DOS. Anyway, if you want to try: 1) get grub4dos from here: http://grub4dos.chenall.net/downloads/grub4dos-0.4.6a-2019-12-30/ http://dl.grub4dos.chenall.net/grub4dos-0.4.6a-2019-12-30.7z (this is last version in 2019) 2) from the .7z extract only grub.exe 3) copy it to the first partition, make it active and boot to PC-DOS, and from it run grub.exe 4) you should get to a grub> prompt Otherwise get RMPREPUSB (easiest method): https://www.rmprepusb.com/ and make a bootable USB stick with grub4dos, you will still get to the grub> prompt. Reply when you are at it (one way or the other) and I will suggest you the commands to test. jaclaz