tomasz86

I've uploaded the VMs. Please check your Twitter PM The XP SP3 wtsapi.dll seems to work fine, at least in my system. TeamViewer also works 100% properly - starts on boot and accepts incoming connections. I've tested both connecting from another Windows 2000 system and also from my phone and no problems occurred.

It works now But who uses IE6 anyway? Even on my website which is related specifically to Windows 2000 only 3% of users use it.

No

Nothing really specific at the moment Maybe you could check whether Skype 5.9 works?

Just a quick update. I've checked the new blackwingcat's kernel v2.3 and wtsapi32.dll is still broken... but the good news is that his new user32.dll 5.0.2195.7157 seems to work fine! TeamViewer accepts incoming connections properly. I'm going to wait until tomorrow to upload a new daily as I want to test everything more thoroughly.

I've found out that TeamViewer works with blackwingcat's user32.dll 5.0.2195.7140 while it doesn't with the newest one which is user32.dll 5.0.2195.7156. The following APIs have been added since 5.0.2195.7140: ChangeWindowMessageFilter DisableProcessWindowsGhosting DwmHintDxUpdate GetLayeredWindowAttributes IsProcessDPIAware IsThreadDesktopComposited IsWinEventHookInstalled PrintWindow SetProcessDPIAware I believe that one of them must be breaking TeamViewer. I've just uploaded a new daily with user32.dll 5.0.2195.7140 so you can test this one I'll try it right now. I can also send you the VM files so you can check the problem yourself.

TeamViewer works Winsta.dll is required for XP's wtsapi.dll to work. I'm now going to figure out exactly which version of blackwingcat's user32.dll causes the second problem with TeamViewer because I'm examining it right now and it seems that the issue is non-existent with the older ones. By the way, there are bugs when WildBill's user32.dll is used instead of it. Broken icons aren't a major problem but there are also much more serious ones, ex. the newest Opera doesn't start at all.

User32.dll is broken too... It causes TeamViewer to refuse incoming connections saying "authentication rejected". To sum up: Wtsapi32.dll causes TeamViewer not to start properly on boot. User32.dll blocks incoming connections in TeamViewer. I've just uploaded a new daily release of UURollup-v11. This one is very experimental. I've replaced wtsapi32.dll with wtsapi32.dll 5.1.2600.5512 from XP SP3 and added winsta.dll 5.1.2600.5512 from XP SP3 because the first one depends on it. I've also replaced user32.dll with the last version of WildBill's user32.dll which is 5.0.2195.7138. I've got no idea how system will work with these files. It does boot up. Icons may look strange due to the old user32.dll.

blackwingcat did change something in his kernel32.dll but it was done earlier in January. I just didn't have time to test "proper" slipstreaming of the file since then up to yesterday when I did and found out that the file could be slipstreamed normally without using any "tricks". I only changed structure of the UURollup-v11 daily package but still it affected only the way it is slipstreamed now. There is no difference in case of manual installation.

Wtsapi.dll 5.0.2134.4 is broken.

There is a bug in UURollup, and it's a very old bug because it's present even in UURollup-v6... I'm now testing TeamViewer and basically what happens is that some of TeamViewer's processes don't start on boot: Windows 2000 SP4 + USP5.1 + UR2: TeamViewer_Serv, TeamViewer.exe, tv_w32.exe Windows 2000 SP4 + USP5.1 + UR2 + UURollup-v6 (and newer): TeamViewer_Serv Basically speaking, the two other processes don't start after UURollup has been installed. I don't know yet which file(s) may cause such an issue and also have no access to versions of UURollup older than v6 so I'm now examining UURollup-v6 in order to find out where the problem lies. There exist also a possibility that it's not a file but rather a registry setting to cause the problem.

It seems like the 81 files from Win XP SP3 works well and are newer than MDAC 2.82 far as the date I have been running them on my hybrid machine and they seem to be working well so far I'm sorry for being 1 month late to reply but I just want to say that many (most?) of the files included in XP SP3 have just a newer date but their functionality is still the same. On the other hand, the files from Windows 2003 Server SP2 (from 2007) may offer more while being "older" than the same files from XP SP3 (from 2008). In one word - those dates don't really mean anything in most cases.

Strange. There's really no way that the few files added in the last daily releases of UURollup-v11 could affect system in any noticeable way. The core files like kernel32.dll, ntdll.dll and others haven't changed for a while since the last version of blackwingcat's kernel which was released on 2013-01-29. By the way, I've just uploaded a new HFSLIP_ia.7z package with all the latest updates. I've also added new updates to the Windows 2000 Updates List for HFSLIP (changelog). There are 8 new system / IE / DX9 updates and the important thing is that all of them are the official updates released by M$. I've also polished my website a little bit and I'm going to simplify it more in the near future (without removing the important content). I'm also going to add some more useful guidelines, etc. Edit: At the moment I'm going to investigate into the TeamViewer issue because it's crucial to myself and I need to have TeamViewer running 100% stable. At the moment it does somewhat work but there are some issues with it which don't occur in stock Win2k. blackwingcat keeps saying that in his environment TeamViewer works properly so I'm very curious what the culprit in this case is.

Has the problem again occurred after you reinstalled the system? What source did you use? Was it fully updated?

I know that problem with nVIDIA drivers as I experienced exactly the same thing when testing dozens of nVIDIA graphics drivers' versions some time ago. In one word - those drivers are buggy. You can "fix" them by disabling one of the services installed by them (don't remember which one exactly) but I'd suggest using a different version.

You need to disable hardware acceleration in Firefox settings. I think you should be able to access them if you boot your system into VGA mode (you can select it after pressing F8 before boot screen shows up). Once set, you can safely reboot the system and start Firefox normally. Do you remember which release of UURollupv-11 you had before? There have been no significant changes in the last few releases. To be more specific: No difference between d130223 and d130222 when it comes to files installed. Three new files in d130222 compared to d130216 (filemgmt.dll, regedit.exe and timeout.exe). Japanese urlmon.dll from d130214 was replaced with the English file in d130216. None of these changes could really make any difference in system core functionalities. Could you also check Firefox 11 Portable from here? Edit: I'm writing from Firefox 11 right now and I've checked the weather website. Nothing strange happened but it also doesn't seem to be loaded properly in Firefox 11 while everything seemed fine in the newest version of Firefox (v19) which I use normally.

No problems in my system with the newest daily of UURollup-v11 installed... Which version of Firefox are you using? Could you do a separate installation of Firefox Portable and check the website there?

What's the URL?

I've just uploaded a new daily release of UURollup-v11 This one is a very important update because it seems that blackwingcat has fixed problems related to kernel32.dll and now it's possible to slipstream the file directly without using any dirty tricks. It means that the newest version of kernel32.dll is slipstreamed and not installed later after the system has been installed was done for a while. All the other files which depend on the new kernel32.dll also can be slipstreamed, thus it was possible to remove the older versions of them. You can see this clearly if you compare file size of this daily release with the previous ones. It's a few MBs smaller. You can also expect a new weekly release tomorrow.

A new daily release of UURollup-v11 is ready. Some small fixes and two new files from Windows 2003 Server added - timeout.exe and regedit.exe. Using the latter it's now possible to change registry permissions without using regedt32.exe: @bphlpt No but I'm pretty sure that Mim0 reads all threads from the HFSLIP forum. He's just implementing changes very slowly (not saying that it's necessary a bad thing) and I needed this one immediately since the script wasn't working for me. The modified script is available only in the HFSLIP_ia.7z package and you don't need it unless you experience the bug mentioned earlier. By the way, thanks to all of you who've uploaded the log files There are still some minor issues in the .NET Framework installer and I'm going to have a look at them before the next release.

I've just done some testing. The last version of Skype where you can send messages is 5.9.0.123. Sending messages doesn't work starting from versions 5.10.x.x. I've uploaded some of the older Skype versions to my Download Archive (navigate to Programs/Skype). After installing Skype 5.9.0.123 make sure that automatic updates are disabled in its settings. Just in case here you can find changelog for Skype 5.10. Edit: This registry entry seems to do the job when it comes to blocking Skype autoupdates: Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Skype\Phone] "DisableVersionCheckPolicy"=dword:00000001

Unpack the archive. Go to i386\update. Open update.inf and under [Version] set "LanguageType" to "0x00", and also remove all entries under all [ProductCatalogsToInstall*] sections. Save the changes and run update.exe. Most of your system will probably change into English after the installation.

@My2GirlsDad Log files are always welcomed We can now use this Google Drive folder to share files (having a Google Account is required though). Please just add your nickname in front of the filename so I'll now whose file it is. There's only one difference between the two HFSLIP versions: http://www.msfn.org/board/topic/158603-strange-bug-in-hfslip-related-to-short-83-names/ I'd recommend using my modified version (at least for Windows 2000).

I'll try to prepare such an image. The problem is not about receiving but about sending messages. Nothing happens when you click ENTER. Edit: I've just send you the file on Twitter. Please check your PM.

I still use a CRT monitor but in case of LCDs the most important specification for me is how large is its pixel pitch. I personally wouldn't take anything with pixel pitch smaller than 0.290 mm, especially if you read / write a lot (like I do).