Drugwash

Gomen, I wish I had enough time and brains power to learn Japanese - would've come in handy right now. My main development machine is a Windows98SE with KernelEx and VC6 and only a couple days ago I installed VC2003 on a XP machine for some testing. Unfortunately VC2008 or 2010 are way out of my reach. And most of the C/C++ knowledge, to be honest. Moreover, it seems Mozilla are advancing in SQLite library versions with every major Firefox version, as the official SQLite advances too. I've had some incompatibilities between 3.7.17 and 3.8.0.2 in my scripts and I would bet this would happen with older versions too. Therefore, which Firefox version would be best targeted for library rebuild, since it would be quite unfeasible to build a whole range of mozsqlite3 libraries for different Firefox versions? I've come to this point with my own wrapper where I wonder if older versions should be supported or just stick with whatever is the latest currently. Personally I like to give and be given choices, but sometimes it's tough. What do you think? Oh and I just cracked open the installer for Firefox 24 - it doesn't have any mozsqlite3.dll inside. Unless it's being built on spot through some delta package or retrieved online (unlikely), we might just be in for a surprise.

Thank you. Since you mentioned SQLite3, I should say that I've been working on an AHK wrapper for the official version and in the process I noticed it would fail unless KernelEx compatibility is set specifically to Windows 98SE or Windows ME. Any other compatibility mode would yield library failure. Even so, I still have other glitches which may or may not be due to my scripts. Observations were made on a Windows98SE machine with KernelEx 4.5.2. I wonder, if you could rebuild mozsqlite3.dll in recent Firefox versions that can be run under Win9x, without VC2010 runtime dependencies and with the right patches to work in 98SE/ME without special compatibility mode set, could that fix once and for all the missing bookmarks and other features, considering those are being manipulated through SQLite3 databases? It's an idea...

GeForce 2 through FX drivers for Win9x and up: http://www.nvidia.com/object/wdm_drivers.html Geforce FX5500 WHQL for WinXP http://www.nvidia.com/object/winxp_175.19_whql.html (found by clicking 'Beta and older Drivers': http://www.nvidia.com/Download/Find.aspx?lang=en-us )

The system may be missing other necessary files/packages. Try running the Opera executable through Dependency Walker and take note of the modules/API that appear in red color in the log window at the bottom (Use 'Start profiling' button in the toolbar and mark all options in the subsequent settings window). Also look in the tree at the top-left for missing files/API marks. That should help you get an idea about what's wrong. If you have a reliable backup system, you may back up the active partition (Windows folder, etc) just to be on the safe side and install the Unofficial Service Pack 3.x which may solve this (and other) problem. If you do that, remember to first uninstall KernelEx, install uSP3, then reinstall KernelEx.

Make sure both devices share the same Workgroup. Try Trout player.

Just as I thought. Thank you.

In this particular case (the FileInfo TC plug-in), only the file headers are being retrieved from the actual file, not the entire file, so there may not be any problem[1]. Although the plug-in has the ability to disassemble the analyzed file (if the corresponding option is enabled in its .ini file), hopefully nobody would attempt to do that on a 4GB+ file. I have no idea if there is any hardcoded filesize limit for the Disassemble option in this plug-in. Now, if we consider the implementation of GetFileSizeEx() in KernelEx, obviously other applications may use it and there's a chance they may actually try to perform operations on those files (copy/move/edit). How could we best handle the situation, when files larger than 4GB are being accessed over the network: should KernelEx's GetFileSizeEx() return an error, should it return the full size or should it return the maximum allowed FAT32 size, thus fragmenting the file? I suppose the latter - although possible - would be unfair and possibly dangerous. But the others would also produce an error in the application and it would all depend on how errors are handled by each application. So probably the best solution would be to return the full size and let the application deal with the impossibility of handling the file; if the value is for display only, then it better be accurate. 1. There may be problems with setting/moving/getting file pointer when reading from the end of the file though.

To be honest, I wouldn't be so sure. I'd rather die before my pants get brown in the rear too often.

Vivere e sovvravivere non sono la stessa cosa. I know what DW can do and I know it can miss some things unless the target is put to work in all possible modes. There may also be different kinds of targets (such as scrambled UPX-ed executables, for example) that need to be checked, to make sure every possible dependencies have been called at some point. But I don't have a TC8 installation on a supported OS and most likely won't have one anytime soon, so maybe someone else who does could perform the required tests and share the results. Or we could continue surviving...

FileInfo itself shows all file dependencies and all APIs used by the target file. So it can be used to reveal any missing files/APIs (as shown above). However, sometimes -as is the case with drivers and possibly other files - certain dependencies are well hidden inside the code and will only show up at run time (wdmcheck may help on occasions). That's what I meant with my final question. If no such hidden dependencies exist, then enhancing KernelEx with GetFileSizeEx() would at least theoretically fix it. There is another problem, that FileInfo 2.2x versions only run on Total Commander 8.x (as the author mentioned in the TC forums). I still use one of the earlier 7.x versions, for various reasons. And recently, when I tried to update a bunch of plug-ins, I sadly found out that most of them wouldn't support Win9x, so I had to revert to older versions. For that reason (among others) I keep my current version of TC, just to make sure old plug-ins work correctly. And for the same reason I stopped checking for updates long time ago, that's why I didn't know about the new 2.2x versions (which may as well be the case with the original poster). I don't know if you use TC or how often, but I can honestly say - and please don't take me as an advertiser - that I could never use a Windows machine without TC and its plug-ins. I've got used to it since 1999 or so and it immediately became my most reliable and useful tool. For people like me, switching to something else can be (almost) impossible. I'm speaking from the heart here.

According to author's page, at least the few crash conditions fixed in v2.20 would entitle a user to update. Also v2.21 adds a couple useful features and a few more fixes. Dunno how vital all of these new features are, but for the occasional developer or advanced user they would sure be of help at times. As for the crashes, they sure are annoying and anyone using FileInfo often (and I, for one, do) would gladly do without. A much bigger question is "would there be any other hidden dependencies that could surface after adding GetFileSizeEx() to KernelEx"?

Probably. Just needs a safety check for results that overcome the max FAT32 size that could be read through network from a NTFS partition. I'm not sure how the plug-in, OS, etc would react when such large result is returned, under Win9x. Is there any more activity in the KernelEx department? Haven't seen any update at Leyok's repository in quite some time. Is there any other attempt known?

The screenshot in post #2 gives the hint: missing API in kernel32.dll. A simple check in the Imports/Exports tab selecting kernel32.dll will reveal the missing API: GetFileSizeEx(). Unfortunately, the file cannot be hexed to call GetFileSize() instead, because the result is returned in a different manner. It would require more changes in the source code, which Fran­çois Gannier - the author - did not release publicly. Latest version of FileInfo that works in 98SE is 2.0.10.0 released november 2007.

IE usually was needed for certain updated system files it had bundled, that could not be found otherwise. It is not about using IE as a browser, but getting those files into the system. One may well rename iexplore.exe to whatever else (mine is iexplore.exe.000) and set some other browser as default. The idea was to have any possible combination for download on the main uSP page, such as: - uSP FULL (standard uSP + IE6-SP1 + DirectX 9.0c) [For deployment in web-isolated environments] - uSP Standard [regular package] - DirectX 9.0c [standalone DirectX, latest 98SE/ME version - required by certain uSP options] - IE6 SP1 [standalone IE6, latest 98SE/ME version - required by certain uSP options] That should cover any and all possible demands. A smart installer with two separate package scripts could build both Full and Standard packages with a single click each.

I agree that a full-blown SP package would be difficult to download for slow/limited connection users (such as myself) and it may also drive away some people at seeing the size of it. It would also take a lot of HDD space, as it would have to unpack all the bundled packages whether they're needed or not and sometimes free space may not be enough for unpacking/storage and installation. I also agree that since certain options in the SP require either DirectX or IE6, users should be well aware of these requirements and be able to readily get them. Would it be possible (legally and bandwidth-wise) to host these additional packages at the same place as the SP? The current installer used to pack/unpack the SP is rather simple. There would be a need for a more flexible one that would allow both opening a bundled help file (the CHM file) by a simple button click and opening any web pages needed for more documentation or download, such as the DirectX or IE6-SP1 packages, through visible links. Some time ago I had suggested PROBLEMCHYLD the usage of the NSIS installer, same that is used by the KernelEx package or Winamp, for that matter. Thing is, we need someone that knows the syntax used for setting the options correctly. I was wondering, Mr. Loew, could you help in this matter? Or anybody else that knows that syntax well enough? I was thinking, the installer should be wise enough to automatically inform the user about the requirements and offer to download the necessary package(s), when certain options are marked. Of course, an Internet connection should already be available, which is another thing the SP should check for, because one may well copy the SP to a web-isolated machine through CD/DVD/USB, in which case downloading would be impossible and user should be notified about it. For such situation, a full-blown SP package could be provided, but the download page should explicitly mention which is what, so that nobody would download unneeded or wrong package(s).

You're welcome! If you analyze the structure of the links (all filters disabled), you'll see it's one URL calling another URL. In certain conditions, add-ons/filters/etc consider this practice as suspicious and simply remove everything but the latest "readable" URL from the whole link, that is why clicking the webarchive links will always go to the original URL instead of the redirected one. I've never used Proxomitron so can't speak about it, but in case of Redirect Cleaner which I always use, one can always see the usable address (URL) when hovering a link in a page. By toggling the Redirect Cleaner button in the statusbar, the address will change accordingly and will show whether it's gonna run through webarchive (when disabled) or the original URL, stripped from redirector (when enabled). This goes for any other page/service that uses such redirection, so it's best to keep the idea in mind and always check whether the redirection is allowed and it's safe to follow it. In addition, NoScript can also block some redirections, but it usually displays that in a topbar, with a button to allow it. That one can be missed too, sometimes.

Well now, since I accidentally landed here, I'd like to add to the knowldge by telling anyone that uses Redirect Cleaner in Firefox (or other browser, if available) to temporarily disable it for such webarchive links, or they will get the very same result as duffy98 earlier. I know it's easy to forget about it, it happens to me pretty frequently (but I'm absent-minded by definition).

Try this one: http://web.archive.org/web/20051231084758/http://download.microsoft.com/download/0/e/0/0e05231b-6bd1-4def-a216-c656fbd22b4e/W95ws2setup.exe

Relevant info is retrieved from a struct and yes, some values in certain fields will differ, such as free memory, system load, etc. But the amount of physically installed memory should have no reason to differ between calls, unless there's a bug in the API and even that might exist or not according to the OS version running. I've developed the above application under and mainly for 98SE, therefore I had to use the simple version of the API, not the extended one. For any 32-bit Windows it should work fine. Of course, 64-bit Windows that can accept more than 4GB of RAM should use the extended version of the API instead, for an accurate result. I could build a x64-compatible version of the application but I have no x64 system to test it on.

There's a Windows API to retrieve RAM information. GlobalMemoryStatus() works on any 32-bit Windows. It can show a maximum of 4GB. GlobalMemoryStatusEx() works on XP and later, both 32-bit and 64-bit. More info at MSDN. Here's a small utility developed by myself in AutoHotkey, that shows amount of RAM, swap file and total load, using GlobalMemoryStatus() : MemPanel 1.0.1.0 (added screenshot)

Thanks, I do what I can. AFAIK, MDGx's site has some kind of safety mechanism that may block crawlers such as WinHTTrack. Haven't tried though, it may just work, but it'd take a lot of time and HDD space. I don't trust WebArchive, too many times it's been throwing weird errors such as "the machine serving this file is momentarily down, please try later" or things like that, only for Win9x-related pages or files. That's too much of a coincidence, IMHO. And many other pages may just be automatically redirected to their current versions - that happened to me too, no matter what I tried. Link to 1.0.5 package has been added above, please someone check it. Thank you.

Dates and version match. Here's the files: FIX95CPU USBSTR95 OSR2SP1 v1.0.5 Mirroring MDGx's site would be quite an endeavour, assuming there's still anything left there. I can't take on this task, as I have neither free space left, nor unlimited download quota or large bandwidth (GPRS modem 7.2Mbps connection, 5GB monthly download quota). I really hope it's just a temporary quirk due to reorganization of files/pages, but in any case, we should have at least another backup, just for safety. Not to mention a lot of the resources are links to now dead MS pages/files since they may have not been redistributable or too large in size. (added SP1 link - thanks LoneCrusader for the integrity check!)

I barely found OSR2SP1 1.0.4 and 1.0.5 Full on my HDDs, together with the other two. But USBSTR95 is dated back in December 2007 and FIX95CPU is from April 2010 - I wonder if those are the latest versions. I could host them at my repository, if needed, except maybe for the large package - not sure if I can upload it there.

I've tried MDGx's links earlier too and they all fall to a 404 page. Either the site is in the process of being reorganized, or it's been hacked. Bear in mind MDGx hasn't been seen here in quite a while, if I'm not mistaken.

Theoretically, the driver should work for any brand and make of cable as long as it uses the respective chipset model (or family) and it may be of use for other devices with same or similar chipsets, unless they're strictly dedicated. There's no harm in trying though. I've recently set up an account at FileDen.com, since my attachment quota here is way overloaded and I also needed a place to store my toys. You may get an account there, it's not very much user-friendly in terms of manipulating files and they don't allow many file types, but it works and it doesn't expire in time (unless they get brought down or out of business). 7-zip archives are allowed but max file size it's 100MB if I'm not mistaken, so a full ISO wouldn't fit. Another alternative is to set up a HTTP or FTP server (easy way would be the beta version of HFS by rejetto), get in touch with the peers by PM, instant messaging, e-mail or anything similar and sent them the link to the package. You'll have to keep the server up until they finish grabbing it though. I used to use HFS years ago but since I'm on a GPRS modem, I can't seem to get through, for some reason - hopefully you won't have such issues. The driver package only, given it's small size, can be sent my mail - just make sure you don't use GMail (as sender or receiver), as they do not allow executables and possibly other files such as DLL, SYS, etc. no matter how packed they are.