jds

I believe that means re-validating functionality that was previously validated in an earlier release. In other words, if a software provides functionality A, B, C, D, and a fix is required for functionality B, full regression testing would mean re-validating functionality A, C and D also. Joe.

A. Background. I have an old HP printer/scanner that I would like to "connect" to a peer-to-peer WiFi network. I also have an older Pentium MMX computer that is doing nothing and could make it happen (yes, I do have a WiFi card that works with it). The problem is that the driver/software disk for the printer/scanner refuses to install, because the minimum processor requirements are a Pentium MMX 233MHz, whereas this one's (a much more common in their day) 200MHz. That's it! The system meets all other requirements (W98SE O/S, RAM, disk space, star sign, etc). Now, this stupidity really riles me! What possible difference is there between a 200MHz and a 233MHz Pentium MMX computer? You would be hard pressed to notice any performance difference, but this seems like elitism, since 233MHz (and 266MHz) Pentium MMX computers were much rarer than 200MHz. This software even refuses to install when I over-clock this computer to 225MHz! B. The theory. So, doing some research, it seems frequency checks such as this are typically performed by reading the Pentium's Time Stamp Counter with the RDTSC instruction and comparing this to a know time source, such as the real time clock. However, it is possible to make the RDTSC instruction privileged, so that user-mode (ring 3) applications (such as the above install software) will trigger an exception when they try to do so. The exception can be trapped by a handler, which can then simulate a Time Stamp Counter that is running at a different (faster) rate. This is tricky stuff, involving some code that must run in ring 0, but at least it's easier to get there in W9X than in NT. C. The practice. Well, it's been about two months of research and struggle, many lock-ups, reboots, crashes, etc., but I've reached the stage where I can at least make the RDTSC instruction privileged, and thereby cause the above installation software to terminate with an error when it attempts to measure the processor speed. But I can't seem to get it as far as to simulate a faster TSC (I plan to quadruple the apparent processor speed) for other (external) applications. If I invoke the RSTSC instruction within the same application, the exception gets trapped and the value returned is quadrupled. But for other (external) applications, an exception is generated but not intercepted. Perhaps a fresh pair of eyes from someone more experienced in system programming can see what I'm doing wrong??? I'm at my wit's end. The source code is attached. It's mainly assembly code within a Delphi skeleton. (Note that since I have Delphi 5, I have to hand-code the RDTSC instruction and instructions involving the CR4 register. Maybe newer versions of Delphi don't need this). Joe. quad_tsc.zip

It should be.... and the simultaneous multiple file copies unofficial shell32 v. 634 should also be so. In any case, just for the record, Win ME defragmenter should be subject to the same limitations than scandiskw, since they depend on the same DskMaint.dll, so it should be good with all partitions smaller than 320 GB or so, and maybe with bigger ones, too. However, DskMaint.dll is a NE executable (16-bit), and as such, has intrinsic limitations in its use of memory that wouldnt be there if it were a PE executable (Win32). Thanks for the clarification. Check. Unofficial 'COPY2GB.EXE' and 'SHELL98.EXE' updates. Since Multibooter says FAT32 partitions beyond 192G in size may not be safe anyway, that means the WinME defragger (and presumably the W98 one, albeit slower) should be a perfectly good choice (with the above updates). Joe.

Previously I have seen here recommendations to use the WinME defrag on W98, I know it's supposed to be a lot faster, not sure what other virtues it may have. What error/symptom did you get with it? Also, is the unofficial 'COPY2GB.EXE' patch relevant here? Joe.

Hi jaclaz, No, I am not saying that. I'm simply saying that "rsaenh.dll" is sufficient. We are actually in agreement. Joe. PS. BTW, I did a minor edit earlier, I had written "first and second", which obviously should have been "first and third".

The evidence is that indeed, only one of these is needed to trigger the 128 bit sub-version of the patch (albeit 4.10.2226, whereas the 56 bit sub-version is up to 4.10.2228), since the first and third files in the above list don't even exist on my system. Anyway, some updated information : On my W98SE system with IE6SP1, again, the only file I needed to temporarily substitute to trigger the 128 bit patch was 'rsaenh.dll' from 'ie5dom.exe'. This is version 5.00.1877.3, dated 1999/9/3. The version that 'dsclient.exe' (and I'm sure, the earlier 'dsclient.msi' ) doesn't recognize properly is version 5.00.1877.8, dated 1999/8/17 (yep, the later version has an earlier date!). This is the version in 'ie501dom.exe' and also 'iedom.cab' from IE5.01SP2, IE5.5 and IE6.0SP1. Joe.

Q.E.D. http://en.wikipedia.org/wiki/Q.E.D. jaclaz I presume "DSClient setup uses instsec.dll to write 128-bit secur32.dll" means something like : rundll32 instsec.dll,SomeEntryPoint OK, by trial and error, I've determined that the only DLL that needed replacing (temporarily) with its counterpart from 'ie5dom.exe' on my (existing) IE5.01SP2 (128 bit) installation, to convince 'dsclient.exe' (5.00.2920.0005) to produce the 128 bit sub-version of 'secur32.dll', was rsaenh.dll. The files sch128c.dll, schanel.dll and rsaenhs.dll must not be relevant, as they do not even exist on this system. Nothing more (eg. registering a DLL) was necessary. For IE5.5 and IE6.0, it's possible other DLL's may need to be temporarily replaced, so that 'ie5dom.exe' can recognise the system as 128 bit security enabled. Joe.

Seconded! Tihiy hasn't merely changed one byte in the code, he's also updated all the version information, etc. Very neat! Joe.

Hi Jake, please see "Fourth experiment" in my previous post. This shows all I did (inc. files I copied) to produce the 128 bit version of 'secur32.dll' on my machine with IE5.01SP2, which might be enough with IE6 (I'll be trying this myself as soon as I have a chance). The 'sch128c.dll' file was not included. No worries. (BTW, I've been away, but in any case, I'm not on the web everyday) Anyway, here are the requested statistics : File = SECUR32.DLL version 4.10.2226, 128-bit build Description = Microsoft Win32 Security Services (US and Canada Only) Size = 59904 MD5 = 8854c4fb59b506e53c5a4200142d188e SHA1 = de40257dffa532eb8f4d9cbfc3e518d229dcf5ab CRC32 = 7500186b Joe. PS. You guys/gals sure have been busy sleuthing! PPS. OK, I need to catch up on some sleep now!

Actually, I'd not heard of this before. I've now seen it in a KB, but there was no download link. Same old propaganda, regurgitated by so-called experts that can't think for themselves. Beware security of W98 machines, make sure they're guarded from physical access, they use FAT, whereas NT machines are so much more secure thanks to NTFS. Yeah right, a proprietary file system without a publicly available specification may hamper recovery efforts, but it doesn't stop an intruder getting in. Well, jds has the right attitude to be our lab rat and report. Since the "high encryption packs": http://www.microsoft.com/windows/ie/ie6/downloads/recommended/128bit/default.mspx Contain: ADVPACK.DLL enhsig.dll ie5dom.inf rsaenh.dll sch128c.dll W95INF16.DLL W95INF32.DLL I would suspect a check for one of the bolded files (or a specific version of them), but let's wait for test results. jaclaz Well, I have some success to report! # First experiment. Dusted off an old laptop with W98FE … Initially, IE was 4.01, with 40 bit encryption. Installed 'dun14-SE.exe', but IE remained at 40 bit encryption! Installed 'ie4dom.exe', now IE had 128 bit encryption. Installed 'dsclient.exe' 5.00.2920.0005, 'secur32.dll' was now 4.10.2226 - 128 bit!!! It was a bit of a surprise to see the 4.10.2226 version number for 'secur32.dll', since the 56 bit sub-version within the above 'dsclient.exe' file is version 4.10.2228. I thought perhaps this lower version number was due to this being W98FE. Note, see for a link to 'dsclient.exe' 5.00.2920.0005. # Second experiment. Dusted off an old laptop with W98SE … Initially, IE was 5.0, with 40 bit encryption & 'secur32.dll' was 4.10.2222 - 56 bit. Installed 'ie5dom.exe', now IE had 128 bit encryption. Installed 'dsclient.exe' 5.00.2920.0005, 'secur32.dll' was now 4.10.2226 - 128 bit!! OK, now where did that 4.10.2226 version of 'secur32.dll' come from? Comparing to the W98FE one, it was the same file. It could not have been produced by patching the original file, since that would be impractical (original version could be anything) and the 4.10.2228 (56 bit) version was too different. So 'dsclient.exe' must have this 128 bit sub-version of 'secur32.dll' hidden somewhere within it. The fact that it had a lower version number than the 56 bit sub-version suggests that MS only bothered to produce a 56 bit version of this hotfix. This is [edit: the word "possibly" should go here, since this is just one interpretation] implied by http://support.microsoft.com/kb/267879 which states : # Third experiment. The '266772usa8.exe' hotfix … Perhaps this hotfix can provide a 128 bit subversion of 'secur32.dll' 4.10.2228? Well, applying this hotfix to the above W98SE laptop updated the version of 'secur32.dll', BUT now it was 56 bit again! Re-applying 'dsclient.exe' did not change it back to 4.10.2226 (128 bit). Deleting 'secur32.dll' (in DOS mode) and re-applying 'dsclient.exe' did. # Fourth experiment. Those "high encryption pack" files … Of those files listed above, the following were present on the W98SE laptop : 'ADVPACK.DLL', 'enhsig.dll', 'rsaenh.dll', 'W95INF16.DLL' and 'W95INF32.DLL'. These files were copied onto the W98SE desktop with IE 5.01SP2 mentioned at the outset of this thread, after first backing up the existing files. Deleting the 'secur32.dll' file (in DOS mode) and applying 'dsclient.exe' 5.00.2920.0005 resulted in the 128 bit sub-version of 'secur32.dll' 4.10.2226! (The above substituted files were then restored.) # Conclusions … Yes, 128 bit sub-version(s) of 'secur32.dll' really DO exist. The latest proven to exist is version 4.10.2226. The 'dsclient.exe' package (similarly, the MSI packages) create the 128 bit sub-version(s) of 'secur32.dll' only if they detect IE is at 128 bit encryption. Unfortunately, this detection is flawed, it seems to work for IE 4 and IE 5.0, but seems to fail for newer editions of IE (or may be affected by updates). It can be forced to recognise that IE is at 128 bit encryption level by copying the "high encryption pack" files mentioned above (probably only one of these files is key). # Caution … The 4.10.2226 version of 'secur32.dll' has a Unicode bug, identified in http://support.microsoft.com/kb/266772 . This may be the reason why 'cntlm' (an NTLM authentication proxy) failed for me, after installing the 128 bit sub-version of this file. I rectified this by copying the (56 bit) sub-version of 'secur32.dll' 4.10.2228 into the same directory as 'cntlm.exe'. Joe.

Thanks for that info. It explains why IE can have 128 bit encryption despite SECUR32.DLL. Yeah! That's pretty similar to what I'm facing now. Pity there was no resolution. That's right, older versions of SECUR32.DLL do no differentiate Export vs US/Canada sub-versions. I think that's because this was before the 128 bit encryption for NTLMv2 was added. So only newer versions have that split. Yes, I encountered this too, which is the reason why I've tried this on W98 machines with both IE6 and IE5, as it is implied that the DSClient install incorrectly determines the encryption capabilities of IE6. However, I didn't get any different result in either case. ---------------------------- The KB's suggest that the DSClient installer package checks the security capability (56 vs 128 bit encryption) of your IE installation, to decide if you qualify for the 56 bit (Export) or 128 bit (US/Canada) capable sub-versions of SECUR32.DLL. But as usual, it seems the detection logic is faulty, and nothing I've tried so far has been successful. Now that 128 bit NTLMv2 is becoming mandatory (by default), this is a real problem. The alternative theory is that all the stuff in the KB's describing these two sub-versions is pure fantasy. That's why I question if anyone has ever seen the 128 bit version of SECUR32.DLL as described (ie. identified as "(US and Canada only)" in its version description). I guess that version description comes from the time when 128 bit encryption software was restricted to USA and Canada (I can't recall when that restriction eased, although it must have been around the time of IE 5.5). The various DSClient installer packages seem to contain only the "Export" version of SECUR32.DLL when you open them with TugZip or 7Zip. Different versions seem to exist for W95, W98 and W98SE. Perhaps the "US and Canada only" sub-version is produced by the DSClient installer by patching the "Export" version. The only new lead I've encountered in the past day or so, is that the Q323466 update for DSClient (not clear from the archived KB just what that update fixes) is (also?) included in a file called "5234_ENU_i386_zip.exe". Haven't been able to locate it, nor do I know if it will be any better at producing the 128 bit version of SECUR32.DLL. Joe.

Probably too late, but here's your answer : CTTY is a built-in capability of COMMAND.COM Joe.

Because without KernelEx, you wouldn't have got this far. Steven is right. Joe.

Not a good idea to default everything to XP. Any applications that invoke functions on a per-OS-version basis will be prone to breakage. Better just do EXE's individually. Joe.

Ahhh, I forgot to mention, I've tried installing DUN 1.4 too (I've tried lots of things over the past few days, I'm losing my mind;-)! BTW, there's a KB that says you must uninstall DSCLIENT before installing DUN, after which you can then reinstall DSCLIENT. Unfortunately, that also didn't help (if I recall, DUN didn't do anything to SECUR32.DLL). At this point, I'm wondering if the SECUR32.DLL version as described in the KB's (eg.kb239869) actually exists?! BTW, on the other matter of MDGx's site, it says "This site has been suspended". I hope that's a temporary problem! It was OK 24 hours ago. Joe.

Maybe : ? MDGx has this CD-ROM image mirrored (in about 7 or 8 parts), since the original site is no more. Joe.

Background : I'm investigating connectivity problems of W98SE on a Server 2008 based LAN. Since the IT department is antagonistic to W98SE, any configuration changes (at the server) to help W98SE are basically not an option. From some material I've read, the problem may be that 128 bit encryption for NTLMv2 may be required by default on a Server 2008 LAN.. http://support.microsoft.com/kb/239869 says : Now, I have Internet Explorer 5.01 SP2;Q313829 (5.00.3314.2101) installed, and it says it's 128 bit, yet my SECUR32.DLL file says "Microsoft Win32 Security Services (Export Version)", so that's apparently 56 bit. I've tried installing 'dsclient9x.msi' (Active Directory Client Extension) which installs 'SECUR32.DLL' version 4.10.2226, also '266772USA8.EXE' which installs SECUR32.DLL version 4.10.2228. Despite the latter having "USA" in it's title, still the version string for 'SECUR32.DLL' is indicating "(Export Version)". All these steps individually and/or together are supposed to result in the 128 bit version of 'SECUR32.DL'. So, does the 128 bit version described in the above (and other) KB actually exist??? BTW, same exercise with a W98SE PC with IE6SP1, produced the same result. Also BTW, versions 5.5 and newer of IE are supposed to come with 128 bit encryption as standard, older versions (down to v4, if I recall) can be upgraded to 128 bit, as with the above 5.01SP2. Joe.

I'm using KernelEx without any special settings for ZA 5.5.094.000 and it's all good. I think CharlesF is saying the same thing for his version.. Maybe your newer version of ZA has different execution for 9X vs. NT, so with KernelEx installed, it's making the wrong choice. Joe.

Just an update ... the 'com-t.com' host seems to have become defunct. So, the IO.SYS patch can now be downloaded here : http://jds.atbhost.net/general.html http://www.geocities.ws/j_ds_au/general.html Joe.

No experience with your version of ZA, however, FWIW, I am using version 5.5.094.000 and it's perfectly behaved. I tried a bunch of other firewalls of other makes, all of which were extremely unstable. The first version I tried of ZA was 5.5.094.000, and since it actually worked (shock!), that was the end of my quest. Joe.

OK, if the open-source code is linux-oriented, what may work for you is either 'mingw' or 'cygwin'. I've used the latter to a (very) limited extent, so can't say which is best, it will likely depend on the particular application. After you install your development environment, including all the optional packages that you think or know you need (especially gcc or gpc or whatever is applicable for your sources), you typically type the following in a "bash" (or whatever) shell (ie. the mingw or cygwin port of the linux equivalent of the DOS box) : ./configure make make install With luck you'll get your application. If it's cygwin, it will require "cygwin1.dll" to run. BTW, the last version of cygwin for W9x is 1.5.something (if you exclude the bloated 1.6.6), not sure if 1.7+ will work with KernelEx, but you need to use a W9x version of cygwin to create a W9x version of your selected application anyway. Not sure what the W9x status of 'mingw' is. Finally, you can also produce DOS versions of linux applications (typically with a bunch of porting work) with a similar development environment called 'djgpp' (www.delorie.com). Joe.

Perhaps, but his restriction was really that he needed a solution that was viable for CPM. Using a protocol intended for exactly such "raw" (binary) data transfers, and which includes integrity checking, is what I would call "using the right tool for the job". For example (and going off at a tangent), if you want to FTP something "verbatim", you use binary mode, rather than text mode. The option he was trying in hyperterminal was equivalent to what happens with FTP text mode, intended for console text only. Yet hyperterminal does offer the right tools, some of which are supported in CPM. BTW, I specified xmodem, not zmodem. The former is surely available in CPM, the latter may not be. [Edit : I've now checked and in fact, not only are xmodem and kermit available for CP/M, so too is zmodem! Rather a surprise, given the time frames.] Joe.

Wow!!! ... Foxit Reader 3 resource leaks ... Easy Assembler Shell installer crash ... MS Office 2003 Word/Excel + Viewers ... MS Office 2007 converters [docx only] ... plus all the rest! From one RC to the next, that's quite an impressive list of fixes!!! Amazing work - you guys are champions! Joe. PS. Just downloaded from SF but the download count didn't go up, even after a refresh. Maybe your user base is even greater than you know.

Just a possibility - try adding Windows Family Login [edit: Microsoft Family Logon] as a Client in your W98 PC's Network Properties. Joe.

Thinking more about this, I realize I was thinking of how the BIOS supports ATA (PATA or SATA) drives directly, and how this affects partitioning. I don't know how well this corresponds for USB drives, in case these are supported by newer BIOSes (as my BIOS isn't new), although it possibly still does. At least in older BIOSes, my reference to whether the BIOS is configured to provide LBA-to-CHS translation is not quite relevant here, because in that case, it's the Windows mass storage driver that provides any support that may exist for CHS addressing, and I have no idea if/how this can be configured to choose between "native" or "fake" CHS geometry. Until I have more certainty about this, I'll follow the safest option, as you've recommended, and locate partition boundaries for USB drives, so as to match both "native" (probably 16 for modern drives) and "fake" (almost certainly 255) CHS geometrues. OMG!!! It took quite some time to read this (and the corresponding links to further information), but it is certainly an eye-opener! One of the references however, http://support.microsoft.com/kb/923332/en-us , has been deleted by MS! Fortunately, the Portuguese version hasn't been deleted (yet), so I read that instead and posted the following feedback : "Firstly, WHY HAVE YOU DELETED THE ENGLISH VERSION OF THIS KB?! Secondly, how on Earth did you figure that a starting offset of 2048 sectors for the boot record would solve alignment problems (and hence performance issues), when this is not a multiple of 63, hence isn't the start of a track (cylinder & head combination) and thereby invite incompatibility with existing O/S and tools?! Since the new large sectors are a binary multiple of 512 bytes, the new offset should have been a binary multiple of 63!" The background to all this is that drive manufacturers have started to use 4K sectors internally, translating them into 8 regular sectors to the outside world. The implication is that all your major disk structures, also file clusters, must be aligned to the internal 4KB sectors to achieve best performance. Put another way, we need to make all our boundaries divisible by 4KB (or 8 regular sectors), as well as whatever other constraints already exist (ie., as per this thread). So, the 128MB partition quanta we've just been discussing is fine. However, the normal 63 sector offset (corresponding to 1 track) for the boot sector isn't, this needs to increase to 63x8=504 (regular) sectors. This wastes an extra 7 tracks (441 sectors, or 221kB) but still maintains proper CHS boundaries. What MS did instead with Vista (and now 7), is follow the 4KB multiple requirement (for performance), while totally ignoring the CHS boundaries that most of the existing O/S seem to require, and chosen a huge 2048 sector (1M) offset to the boot sector. Just a little more thought and they could easily have met all requirements. (Maybe someone rather stupid, thought 1MB was a nice round figure?) Joe.