Drugwash

True, but only for people that know what they're doing and are willing to assume any possible inconvenience. There may always be someone who does not know the experimental nature of these builds and unknowingly break their system, so it's fair to issue such warning. Anyway, thank you for testing and I'm sorry it didn't work for you.

Wouldn't the patched HDD driver (ESDI_506.PDR) be required for disks larger than 128GB? The 98SE version can be found here: http://www.mdgx.com/add.htm#BHD Dunno if/where there is a Win95-compatible version. Maybe with a patched HDD driver at least Paragon's NTFS driver would work.

Please note the KernelEx builds at my repository are experimental and untested. Do not install them on working/critical machines. Unfortunately I've been too busy in real life and therefore unable to patch the sources to R9 and build. No idea about the IE error - I used to use SlimBrowser under 98SE but uninstalled it after it started erroring out and replaced it with Firefox 9.0.1.

You can find dosstub.exe in KernelEx4520155_src.7z at my repository - it's a 64 byte file. XP-SP3 (in my tests) does not recognize LOCALAPPDATA as an environment variable - is it only available/declared in newer OS versions? Off-topic, I'd like to know how to programmatically get that variable in NT/2000+ OS versions, for an unrelated script I'm building.

Thank you! Just to make it clear for myself and any others interested: this package is cumulative - meaning it contains all changes since official 4.5.2 - and has to be applied to the official 4.5.2 sources to get to the current 4.5.2015.9, right? I'll set up a separate branch with 4.5.2, apply the above package and check against my old setup, to see what else has to be done to get a full batch in one shot. When ready I'll try to pack up the changed files for further testing.

Hey, jumper, glad to see you back! Have you managed to set up your environment for a full batch compilation? If not, could you please try the R5 at my repository (being latest available at the time of posting) and see if it does the job and it's got no wrong settings or bugs? It would be good to sync our settings so that little to no project changes would be required for each subsequent revision. I currently have no helper tool installed on my 98SE system (such as diff, Tortoise SVN or the like) so I'm doing all the patching manually which is error prone. If you know of such tool that doesn't slow down the system (I remember Tortoise did slow it down badly because of its shell extensions, reason why I uninstalled it years ago), please refer me to it.

Unless you have a strong reason for sticking with Win95, I'd suggest trying Win98SE. It's more flexible, has powerful updates (official and unofficial) and may just fit the job. If you can find an original CD with valid key and the price is affordable then you may try this. Just out of curiosity: how much did the 95 CD cost, all in all and how much would a 98SE one cost, if available at the same store?

Apparently no good deed remains unpunished...

There's something we all missed: the three buttons being grayed out. I presume it's about 'Add...', 'Remove and 'Properties' under the Devices tab. How about the second tab Logging settings, or is it not present there? There should be at least one choice in the dropdown list below 'Logging module', saying 'STICLI'. If that's missing or the tab itself is nonexistent, that may be indicate a missing or unmatched dependency. Direct dependencies for original STICPL.CPL (on my 98SE system) would be: STI.DLL 4.10.1998 (which is an ActiveX object) Kernel32.dll 4.10.2226 Advapi32.dll 4.90.3000 User32.dll 4.10.2233 Gdi32.dll 4.90.3003 Comctl32.dll 5.81 Shell32.dll 4.72.3612.1700 Ole32.dll 4.71.3328 STI.DLL has the following dependencies: Kernel32.dll Advapi32.dll User32.dll Setupapi.dll 5.00.1671.1 Cfgmgr32.dll 4.10.1998 RPCRT4.dll 4.71.3336 Again, those version numbers are present on my system, where the 'Scanners and Cameras' control panel has those three buttons active. Never ever used that applet though. Your versions may be different. I'm thinking of a bad OLE installation. I remember there used to be a tool that checked the validity of all OLE elements installed, but forgot its name.

There's also the possibility that the device is defective - be it the power source, the data communication channel or whatever. I still have a friend's scanner, an old LPT-port Mustek that's been powered with reverse polarity voltage for a few seconds and now doesn't do much other than power on. To rule out hardware issues you may have to install and test it on a newer (Win2000+) system using the corresponding drivers.

Yep, that's more like it. I've been reading that topic you linked to - wolves be there. But the bug itself is difficult to catch and squish. After all the test results, I'd say certain video cards - and especially the X850 XT PE - may require certain additional (or different) commands when switching resolutions (assumingly to/from very low ones) but either the main game exe or the DOS driver (DOS4/GW or DOS32a) don't do it (properly) while running under Windows, possibly due to an intermediary layer that may try a more direct approach. But that's just shooting in the dark. Speaking of dark, I'll go hit the sack - it's past 1AM here.

'Retro' and 'too much' in the same context seem to clash with each-other. Although my old 486 used to sport a whopping 32MB of RAM and I always thought: "man, that's just too much!"

Thanks! MemPanelW is the Unicode version, more appropriate for Win2000+ (although the code is exactly the same, just the underlying interpretor is different). Couldn't test it on any machine with more than 2GiB of RAM but unless there's a bug it should correctly display the whole amount on Win2000+. Did you just test it on a 9x machine with 4GB of RAM? Isn't that a tad too much? The extended version of the API works with unsigned large integers (64bit), while the basic version - found in 9x - only works with 32bit unsigned integers, hence the limitation (probably ranging from 2^0 to 2^31).

Let us all, please, have a little bit of patience until jumper comes in with the answers. No need for hostility.

In which order are these applied and to which sources? A promise is not enough. One can promise to release the source code of a future version, but a version that is out now has no source code of which I am requesting. It is not a matter of promising, it is a requirement to release the sources to comply with the GNU GPLv2 for every build that is released. Also, it would be best to not have a "diff" and instead release full sources as it reduces the liability of violations. It also makes it easier for others who want to contribute to more easily contribute without jumping through hoops of figuring out what gets extracted onto what in a specific order. Say if suddenly the locations of other sources such as SourceForge for 4.5.2 disappear and that the only source code available is in this topic. Although highly unlikely this event will occur it may still happen (other unlikely events have occurred but I will not go into that), those "diff"s are not enough. Full sources are also much simpler to create as you can just archive up your cleaned working copy, or if version control is used they can export archives straight from the repository. Both R3 and R5 are full sources. I have added jumper's new/edited files to the original 4.5.2 and operated a few minor adjustments to the project files in order to compile the whole batch at once. However I'm not very familiar with C/C++ and there may or may not be problems with that setup. Jumper has taken on this task fairly recently and as far as I understand his setup is (or was) not yet completely functional. Releasing garbled sources would not help anyone so he said he would release only after cleaning them up and reaching a stable stage. I do agree that a full source package would be preferrable instead of a diff, but either way it should at least be a working version so personally I see no reason to force a source release. But then again I'm not an expert in legal matters.

Have you tried installing WIA 1.1 from here? Anyway, I had never looked into Scanners and Cameras. Did it just now and it only lists 'General Video Camera Device' which I have no idea what it is. I do have a Lexmark X-1150 combo installed and running fine under my 98SE and in fact I have just scanned a few documents a couple days ago, using the official software. However, I have FastStone Image Viewer 5.3 installed and looked into the File menu under 'Acquire Images From Scanner'. The new window it opens lists in the right-hand dropbox all the cameras and scanners ever installed on my system, with the Lexmark X1100 series as default (as it should be). Therefore, before messing around with the system, you may wanna try FastStone Image Viewer (freeware) and see if you can get your scanner (and other capturing devices) to work with it.

Maybe it uses GlobalMemoryStatus() instead of GlobalMemoryStatusEx(). The former can only acknowledge 2GiB of RAM, while the latter can go all the way up. Same goes for the page file, it's retrieved by the same APIs. Try MemPanel from my repository, it should use the correct API depending on operating system type (Win9x don't have GlobalMemoryStatusEx() implemented). It does detect the whole amount of installed RAM (when less that 2GB as per above) even when it's limited in SYSTEM.INI on 9x systems. I'm not sure if it works under WIn95, couldn't test it.

Jumper already promised some time ago a full diff package for the upcoming Release 10, while the original 4.5.2 sources can be found online. In the mean time, a couple of older intermediary versions (R3 and R5) with a few minor project fixes can be found at my repository here.

By all means do! At least theoretically they should match the hardware as good as possible (for the release time). Also make sure DirectX is correctly installed. Drivers should work with 9.0c. Better check any Readme/FAQ/etc available on CD in regard to requirements and any possible known incompatibilities/bugs. For best results you may wanna completely eradicate the old video driver first using Driver Cleaner Pro v1.5 (the old non .NET version).

You may be the unlucky owner of a not-so-compatible videocard. On my 98SE machine I have a GeForce4 Ti4200 with AGP8x card manufactured by MSI. Luckily I have the original driver CD (and also got the same download from MSI back in the day). Any - and I mean ANY - generic driver version issued by nVidia would immediately disable AGP texture in my card. DirectX diagnostics shows the respective button grayed out and the feature disabled. Never tried the card under any other operating system. Therefore I would assume such similar issue could happen to you or anybody else with certain videocards tweaked by manufacturer and only usable with certain driver version(s) usually available only from them. (fixed small typo)

Have a look at the five new pictures just uploaded. It's an 1986 model originally with no LEDs. Also manufactured in the UK as yours. Two of the active ones have no original label at all at the bottom, but one has an additional smaller label where I signed myself with the purchase date: Sept 21, 1999 (see pics). That is my very first keyboard ever, still in use today! Third active one has a manufacturing date on the label of Sept 27, 1993. And I had another one that I took with me at work about 8-9 years ago (been a couple months with a printing house) and never got it back. It was fully operational and freshly cleaned, I still regret it. Here we go again hijacking another topic...

I've taken a few quick pictures of my keyboards, they can be found here. You can see the internal metal plate in one picture. I've dismantled each of them at some point, for clean-up but as far as I can remember none of them has the sliding mechanism you mentioned. I wish they did!

Maybe you should try filling up the extended partition with dummy files to check if the BIOS won't wrap around the 8.4GB limit, destroying the Windows files and anything at the beginning of the drive CHS-wise. To avoid reinstalls you may create partition/drive image(s) beforehand, easily restorable.

Yes, that'd be the right term, thank you very much!

Actually I do have such silver conductive paint (quite expensive IMHO) and I did try to fix some tracks using it but the operation failed. Maybe it's too thick (what could I use to dillute it?) or maybe I don't have the proper tools. It is indeed difficult to repair because the plastic panel that holds the keys is bolted riveted (the actual term slips my mind thank you jaclaz for the heads up!) to the metal plate in a lot of places and once they're cut they'd need to be tightened back using very small screws or something else that could hold the plastic panel tight. The key caps can be replaced, there used to be (and maybe still is) a company that manufactured such Model M keyboards and also offered key caps for sale. Shouldn't be a problem for standard English alphabet but what should other people do, when their (preferred/native) keyboad layout contains special characters (such as Romanian, for example, where we have ŞŢÂĂÎ) and such keys are not available? I've always used a (not so) permanent marker for those special keys but the narrow vision of manufactures around the world, now in 21st century, astonishes me.