tomasz86

Do you get this GetIpErrorString problem when trying to launch the program you mentioned before? What's the name of it? You should check the dependencies with Dependency Walker. You will be able to solve the dependency problems with BlackWingCat's KDW. I may help you but first you need to let us know what the name of the program you're trying to use is.

Thank you, WildBill

Yes, I mean MS11-011 (2393802) but you should download it from here as I haven't updated the RyanVM list yet. V6 is the current version. I can't say for sure but I guess that Windows files for European languages should be interchangeable. In the past I already tried using English kernel32.dll in a Polish system and no problems occurred. Of course some system dialogs may change to English but in case of kernel files most of them will be the text which you see on BSODs, not the actual system GUI. Here there's instruction how to change the update.inf file.

WildBill's patch already has this function (TzSpecificLocalTimeToSystemTime) added. If you want to use it then you'll have to apply the English patch to your French system.

Where's your sense of humour, Yzöwl? My comment about locales was related only to this part of your message and wasn't intended to be sarcastic at all. I haven't got time yet to try the method you suggested and yes, I'm a beginner when it comes to batch scripting so I don't understand many of your script suggestions until I try to use them in practice. Please don't look for bad intentions everywhere!

I added December 2011 cumulative time zone update. It's available for all supported 24 languages. Windows2000-UU-KBz2633952-x86-ARA.exe Windows2000-UU-KBz2633952-x86-CHS.exe Windows2000-UU-KBz2633952-x86-CHT.exe Windows2000-UU-KBz2633952-x86-CSY.exe Windows2000-UU-KBz2633952-x86-DAN.exe Windows2000-UU-KBz2633952-x86-DEU.exe Windows2000-UU-KBz2633952-x86-ELL.exe Windows2000-UU-KBz2633952-x86-ENU.exe Windows2000-UU-KBz2633952-x86-ESN.exe Windows2000-UU-KBz2633952-x86-FIN.exe Windows2000-UU-KBz2633952-x86-FRA.exe Windows2000-UU-KBz2633952-x86-HEB.exe Windows2000-UU-KBz2633952-x86-HUN.exe Windows2000-UU-KBz2633952-x86-ITA.exe Windows2000-UU-KBz2633952-x86-JPN.exe Windows2000-UU-KBz2633952-x86-KOR.exe Windows2000-UU-KBz2633952-x86-NLD.exe Windows2000-UU-KBz2633952-x86-NOR.exe Windows2000-UU-KBz2633952-x86-PLK.exe Windows2000-UU-KBz2633952-x86-PTB.exe Windows2000-UU-KBz2633952-x86-PTG.exe Windows2000-UU-KBz2633952-x86-RUS.exe Windows2000-UU-KBz2633952-x86-SVE.exe Windows2000-UU-KBz2633952-x86-TRK.exe

That's why I wrote "system locale" independent, not language independent I'll try to use the temp folder method.

You can still use nLite although not all options will be available. If you want to get rid of the "warning" you can rename "CDROM_ID.5" to "CDROM_IA.5". It'll think it's an Advanced Server system.

But this would make the script system locale dependent which I would like to avoid

This is the final version: :: updating fp40ext.cab SET Counter=0 ECHO.&ECHO.&ECHO Checking fp40ext.cab...&ECHO. MD TEMP\fp40extcab EXPAND -F:* %SP6%\fp40ext.cab TEMP\fp40extcab >NUL IF EXIST HFMER\*.* FOR /F %%I IN ('XCOPY/DUY HFMER\*.* TEMP\fp40extcab\') DO SET /A Counter=!Counter!+1 FOR /F %%I IN ('XCOPY/DUY TEMP\i386\*.* TEMP\fp40extcab\') DO SET /A Counter=!Counter!+1 FOR /F %%I IN ('XCOPY/DUY TEMP\i386\new\*.* TEMP\fp40extcab\') DO SET /A Counter=!Counter!+1 ECHO %Counter% file(s) were added. IF %Counter%.==0. ECHO.&ECHO There are no new files to add. IF NOT %Counter%.==0. ( ECHO.&ECHO Repacking fp40ext.cab... CABARC N %SP6%\fp40ext.cab TEMP\fp40extcab\*.* >NUL ) RD/Q/S TEMP\fp40extcab The thing is that now file names are not displayed at all. I tried to use this: IF EXIST HFMER\*.* FOR /F %%I IN ('XCOPY/DUY HFMER\*.* TEMP\fp40extcab\') ( DO SET /A Counter=!Counter!+1 ECHO Updating %%I ) but while displaying names of the updated files it also displays '0's (when no files are copied) and some other (?) numbers.

It works but %Counter% is displayed as "+1+1+1+1+1+1+1+(and so on) file(s) were added".

You're right (as always ). At the end I've just chosen the simplest method: :: updating fp40ext.cab ECHO.&ECHO.&ECHO Checking fp40ext.cab...&ECHO. MD TEMP\fp40extcab EXPAND -F:* %SP6%\fp40ext.cab TEMP\fp40extcab >NUL IF EXIST HFMER\*.* XCOPY/DUY HFMER\*.* TEMP\fp40extcab\ XCOPY/DUY TEMP\i386\*.* TEMP\fp40extcab\ XCOPY/DUY TEMP\i386\new\*.* TEMP\fp40extcab\ ECHO.&ECHO Repacking fp40ext.cab... CABARC N %SP6%\fp40ext.cab TEMP\fp40extcab\*.* >NUL RD/Q/S TEMP\fp40extcab It doesn't look very pretty but works nevertheless. The only downside is that the cab is repacked even if there are no new files copied.

Of course but then the only difference between the two is: XCOPY/DY 1 Files(s) copied vs. XCOPY/DLY 1 File(s)

I like the XCOPY/U (XCOPY/DUY in this case) method for its simplicity I tested the other one suggested by jaclaz too (XCOPY/DL) but it asks whether to overwrite file or not. Also I'd prefer to have the script language neutral (I myself sometimes switch between different system locales). There is just one more thing related to this part of the script: MD TEMP\fp40extcab EXPAND -F:* %SP6%\fp40ext.cab TEMP\fp40extcab >NUL XCOPY/DUY HFMER\*.* TEMP\fp40extcab\ I need to repack the archive but It'd be nice to have it done only when there are new files copied. Before I used something like this: FOR /F %%I IN ('DIR/B TEMP\fp40extcab') DO ( IF EXIST HFMER\%%I ( ECHO Processing %%I XCOPY/DY HFMER\%%I TEMP\fp40extcab\ >NUL IF NOT EXIST TEMP\fp40extcab\new MD TEMP\fp40extcab\new ) ) IF EXIST TEMP\fp40extcab\new ( ECHO.&ECHO Repacking fp40ext.cab... CABARC N %SP6%\fp40ext.cab TEMP\fp40extcab\*.* >NUL ) ELSE ( ECHO There are no new files to add. ) Quite primitive but did the job more or less Now it's not applicable when the whole loop is replaced by XCOPY with the /U switch. Does anyone have any idea how such a checking could be done? Of course I can just always repack the archive even if there are no new files but it increases the time unnecessarily (especially when cabs such as driver.cab are processed...).

I have one question. I use the following script to update *.cab files (fp40ext.cab in the example) from Win2k SP4 MD TEMP\fp40extcab EXPAND -F:* %SP6%\fp40ext.cab TEMP\fp40extcab >NUL FOR /F %%I IN ('DIR/B TEMP\fp40extcab') DO ( IF EXIST HFMER\%%I ( ECHO Processing %%I XCOPY/DY HFMER\%%I TEMP\fp40extcab\ >NUL ) ) I use XCOPY/DY to copy only files that are newer than the ones in the destination folder. I would be interested in having the "Processing %%I" displayed only when the actual file is copied and replaces the other one. Now it's displayed for all files regardless of whether they are actually copied or not (when they're older). Could it be done in a simple way?

I finally managed to get everything work. Jaclaz was right. The first adapter was too tall to fit in the notebook, even when the SSD was used without its case. I couldn't find any other, flatter one locally so I order this one from eBay. It was actually cheaper than the previous one because the shipping cost was only 1$. It took around 1.5 weaks to get it. First of all, I can say that everything works properly and there are no problems with stability. The SSD is detected properly in the BIOS and also when installing Windows. As it's a 64 GB capacity drive there are no issues with the BIOS too (its limit is 160 GB). I took some pictures of the whole 'operation'. E-IDE cable + previous (tall) adapter + SSD: As you can see it's impossible to use the SSD 'as it is': Samsung 470 can be very easily opened: The Samsung SSD itself is only 1.8' size so it should fit to any laptop designed to work with a 2.5 HDD. I guess it may be important information as the newer model (Samsung 830) is 2.5' so it'll probably not fit when used together with an adapter. The new flat adapter: Samsung 470 detected in BIOS: I did some basic benchmarks. As you can see, performance is heavily affected by the old ATA66 interface and the adapter too: old IDE drive (Samsung HM160HC): SSD (Samsung 470 64GB) The results don't look very promising at the first sight but: 1. Access time difference - 18,2 ms (IDE) vs 0,1 ms (SSD) 2. 4K - huge difference In general, there's a huge different in speed. You can't even compare system responsiveness on the old IDE drive to the current one. I can say that it's like giving a second life to this old machine I want to thank everyone for providing help and useful information, and inspiring me to get this idea materialised although it looked quite unreal in the beginning.

Yes, I've already analysed some files included in HBRs but there's still a lot more to do I hope I'll manage to finish the first part in the next few days. The problem is that it happens randomly (once a few days) even after the cache is flushed. I can't reproduce it, unfortunately. That'd be probably the safest solution. You may also try to play with [OverrideVersionNumbers] but I don't really know if it works. In case you bump the number to a higher than 7081, would be it be difficult to add changes from the original 915985 and BWC's 915985-v2?

WildBill, ntdll.dll 5.0.2195.7080 is included in KB915985 which is a HBR. Bristols uses HBRs so that's probably the reason why your ntdll.dll doesn't install (as its version is lower). By the way, there exist also KB915985-v2 made by BlackWingCat with ntdll.dll 5.0.2195.7081. I've also got one question unrelated to the kernel patch. Can such icon anomalies be caused by 2479628? They can be brought back to normal by changing color depth or resolution.

Hello blackwingcat Do you mean a .dwi file related to wow32.dll? The problem is that it doesn't matter at all. The same freeze occurred when the original W2K's wow32.dll was used and when the one from XP was installed. It doesn't make any difference So far I've already checked the following components: 1. Mainboard - same situation on two different mainboards. 2. HDD - same problem on HDD, SSD, RAID and non-RAID (the controllers were also different). 3. Graphic card - two different cards and no difference. I can't check the CPU as I don't have any other to replace it but I'll try to do some extensive memory testing and see if there's anything wrong with it.

Unfortunately wow32.dll doesn't change anything It must be something else...

I'm reviving this topic because I've still been experiencing the cmd.exe freeze/stack problem. Especially recently I've been using batch scripts a lot and this problem is extremely bothersome I need to reset the computer each time it happens. I can't really say how frequently I encounter it but let's say that if I run a HFSLIP-like script for 5 times, the problem will occur at least once. As I became more and more annoyed, inspired by dencorso I've just tried to replace the original W2k's wow32.dll with the fixed one from XP (+ I added XP's ntvdm.exe to fix the dependencies). I'll see if it makes any difference. Does anyone else have any idea what can be the reason for such freezes (if it's not the wow32.dll)? In meantime I already changed mainboards and used different HDD/SSD on different controllers but it didn't help. Graphic card also doesn't seem to matter.

It's all right now

Something strange's going on 1. I don't have any bootskin setting set. 2. /BOOTLOG is enabled but it's not created because the BSOD happens before boot logging is even started. 3. The strange thing is that regardless of /SOS set or not, the beginning of GUI part is the same and looks as if /SOS was enabled. I can see the GUI part for only half a second before the BSOD appears. 4. The v5 doesn't make any difference. ... I think I found the reason. The BSOD appears only when /PAE is enabled. Interestingly it doesn't affect the desktop as I've just turned /PAE on and no problems here. It was turned on on the notebook by mistake but still there's no BSOD unless I install your patch

The BSOD happens just right after the GUI mode of /SOS startup is loaded. Surprisingly, safe mode works which is an improvement compared to the previous versions when the BSOD appeared during safe mode booting too. It appears before bootlog is created and minidump also is not created when the BSOD happens.

I missed the fact that you already uploaded a v4 I've installed it on both my desktop and laptop computers and while everything seems to work fine here (on the desktop), there's still the same error on the other one: *** STOP: 0x0000001E (0xC0000005, 0xDDC6473E, 0x00000000, 0x0000000C) KMODE_EXCEPTION_NOT_HANDLED *** Address DDC6473E base at DDC00000, DateStamp 4ebda139 - ntoskrnl.exe System specifications are listed in #398