Drugwash

In the mean time, I'm working on an automated installer for Tihiy's package. Unfortunately, information on various settings in the initialization file is quite nonexistant, everybody on the web seems to be satisfied with the default settings. I'll have to perform a few tests on my own and maybe some flexibility will come out of this. If anybody has any in-depth information on svgamode or resolution settings, I'd gladly listen to what they have to say.

Yep, I've read that KB alright, as well as a few others linked to it. They are the masters of if... then, but no actual final solution. I suppose situations like that lead to the development of the Side-by-Side (SxS) system used in later NT-based OS versions. I see no detailed explanation as to which DSClient component might conflict with which hotfix(es) or original system files. There is no map of what breaks and what works if this gets installed. The only attempt at an improvement is DFS.VXD which makes it two out of three, instead of one out of three (Win2k domain logon attempts). Lame, IMHO. But anyway, our uSP installs a newer version of DFS.VXD, namely 4.10.2231, while the KB linked from the main article mentioned by you lists 4.10.2228 - hopefully it's for the best, not for the worst. Other than that, we're lost in the mist. Anybody got a good flashlight to get us outta here? On a side note, related to the Explorer Start menu banner: it can be changed at any time, by using just a couple of tools. First is Resource Hacker and second is one that can kill the Explorer process without triggering its restart. For the latter I use Codestuff Starter, which is a great tool to watch/kill startup/running processes (and services in NT-based OS). Just make sure you get the zip version, as the installer wouldn't run under 9x last time I checked. How to replace banner (or any other resources, for that matter) in Explorer.exe: - unpack your resources, if needed (such as banner bitmaps mentioned by PROBLEMCHYLD, icon packs, AVI files) - start ResHacker - open file explorer.exe (in ResHacker menu > File > Open) from the WINDOWS folder - replace the desired resource(s) - start Codestuff Starter (or whatever other similar tool) and kill explorer.exe; make sure it doesn't restart by itself - save the modified explorer.exe to the same location (a backup will be created automatically, named explorer_original.exe, which can be restored in case of a bad edit) - hit Ctrl + Esc, which should launch a new Explorer process. If that won't happen for some reason, right-click in the upper list of Codestuff Starter, choose New > Browse, goto the WINDOWS folder, select explorer.exe and launch it. If you use another tool, make sure it has the ability to launch a new process. Alternatively, have a secondary file manager already open, Alt+Tab to it and launch explorer.exe from there. That should be all and should cover questions such as "I don't like the default banner and I was reckless enough not to read the instructions on the download page, now how do I put my preferred banner in Explorer?" or anything similar. Enjoy!

Spyware Blaster is a lost cause. I've just tested it, it's not GlobalMemoryStatusEx, it's SetFilePointerEx (at least in the version I downloaded and installed an hour ago). And no, patching the exe to call SetFilePointer instead, won't help - there's a huge error message box. There are too many changes between versions, too many Unicode API called, too many Unicode filenames required by those API. I say it's over with this one. But go ahead if you wanna play - I've already wiped this off my must-have list.

Indeed, I missed the space there. I don't have ME here but I looked through my 98SE and it has both subkeys, which is confusing enough. Probably some newer apps that run in 2000/XP compatibility through KernelEx, create/modify some of the keys and maybe newer system files that come with uSP create them, in the first place. So in 98/ME it's SessionManager and in 2000/XP/later it's Session Manager. What a tiny space can do...

@ Leyok: Thanks for the explanation. Is there a way to communicate with the debugger, from the other machine, to resume operation and/or get more useful information? I use Hyperterminal to watch the boot progress, although I don't like it keeping the message history. Anyway, let me know if there's anything else I can do. @ loblo: Good info! Apparently, XP uses the same location for its pseudo-DOS mode. Anyway, the locations pertaining to VC6 and PSDK, found in the PATH variable string from my post above, should be set in VC6's Executable files section, as mentioned in the same post. This goes for any host OS. In Windows ME, the other variables can be set in the Registry, at the location mentioned by loblo above, if necessary. I'm thinking, the entries in autoexec.bat may be required only when using the tools outside the VC6 environment, that is manually building the projects in commandline mode.

Those settings should work with both Xeno86's version and Ley0k's. I can build both of them without problems. The environment variables in autoexec.bat may not be required by KernelEx, but they're automatically created at PSDK install time and may be needed by other projects, so it may not be a bad idea to have them properly set, especially for those that may wanna use this environment to build other open-source projects. Today I've disabled the debugger on the test machine, compiled the Release version from Ley0k and installed it. Upon reboot, mprexe crashed and subsequently KernelEx reported a failed installation. Manually launching the verify tool reports the same thing. However, the Compatibility tab appears in apps' properties. Kernelex.dll is loaded in mprexe's namespace, kexcom.dll is loaded in explorer's, but neither kexbasen nor kexbases are loaded by any executable. Machine does not hang anymore. I've also disabled the SSDP service (installed by uSP) prior to installing KernelEx - don't know if that had any impact, but reenabling it sure didn't change anything. MPREXE crashes at every boot, otherwise machine appears to be running normally. What else can I do to help? Here's the standard crash report: MPREXE caused an invalid page fault in module KERNEL32.DLL at 0167:bff9e0b7. Registers: EAX=0072f5e0 CS=0167 EIP=bff9e0b7 EFLGS=00000246 EBX=81c08380 SS=016f ESP=0072f430 EBP=0072f5e0 ECX=0000016f DS=016f ESI=00001da7 FS=1da7 EDX=0072f5d0 ES=016f EDI=0000016f GS=0000 Bytes at CS:EIP: cc a1 e0 dc fc bf 8b 00 66 64 f7 05 1c 00 00 00 Stack dump: bfa40000 81c083c4 81c09d9c 81c09d64 81c09d78 c196b220 00000000 0072f5ec ffecbad7 0072f480 0072f464 0000000e 00000007 00000000 00000000 0072f488

@ schwups: VC6 is old, it may not be 100% compatible with newer Windows; should work under ME though. Problem is, ME doesn't have a real DOS and doesn't take into account autoexec.bat, so even if VC6 and PSDK added the required lines, they will not take effect. I wish I had more experience with ME, to know how to overcome this issue. Thing is, VC6 and PSDK need those environment variables to know where to find its tools. If those variables aren't set (which is the job of the autoexec.bat lines), VC6 will fail. Maybe the variables can be set through the registry, but we'll have to wait for someone more knowledgeable to point to the right direction. After that, the rest of the settings I listed in the post above should be checked and properly set. One alternative solution would be to install a virtual machine under Vista, install 98SE and set up VC6, PSDK and the rest of the development environment, then try to compile. Personally I'm not a big fan of virtual environments, always did things on real hardware even if it took much longer (that's what experience builds up from), but in extreme situations such environment may prove useful. Well, it's worth a shot anyway. @ PROBLEMCHYLD: I've always managed to build the project, but only after a few small changes to the projects. Unfortunately, after installing it, the machine hangs upon reboot. I've provided a few debug logs above, hopefully they'd be of some use. Haven't checked out the repository today, see if there's any newer commit; will do that soonish. Please see my reply above to schwups, your problem might be the same, with missing environment variables in autoexec.bat.

All the errors you get are due to incorrect/incomplete installation of the development environment. The file COMPILE.TXT in the root of the KernelEx source folder specifies the prerequisites: - Visual C++ 6.0 SP6 - updated xtree header - Platform SDK february 2003 - Windows 98/2000 DDK In VC6 main menu > Tools > Options > Directories go through all items in the 'Show directories for' list and make sure the order of the items is as follows (that's important!): Executable files C:\Program Files\Microsoft Visual Studio\VC98\BIN C:\Program Files\Microsoft Visual Studio\COMMON\MSDEV98\BIN C:\Program Files\Microsoft Visual Studio\COMMON\TOOLS C:\Program Files\Microsoft Visual Studio\COMMON\TOOLS\WIN95 C:\Program Files\Microsoft SDK\BIN <other> Include files C:\Program Files\Microsoft SDK\INCLUDE C:\Program Files\Microsoft Visual Studio\VC98\INCLUDE C:\Program Files\Microsoft Visual Studio\VC98\MFC\INCLUDE C:\Program Files\Microsoft Visual Studio\VC98\ATL\INCLUDE C:\Program Files\98DDK\INC\WIN98 <other> Library files C:\Program Files\Microsoft SDK\LIB C:\Program Files\Microsoft Visual Studio\VC98\LIB C:\Program Files\Microsoft Visual Studio\VC98\MFC\LIB C:\Program Files\98DDK\LIB\I386\FREE <other> Source files C:\Program Files\Microsoft Visual Studio\VC98\CRT\SRC C:\Program Files\Microsoft Visual Studio\VC98\MFC\SRC <other> Also, if you're running VC6 under Win98/ME (and maybe not only these), there are a few additions required in AUTOEXEC.BAT so the system would know where to get the tools from: SET PATH=%PATH%;C:\PROGRA~1\MICROS~6\Bin;C:\PROGRA~1\MICROS~6\Bin\Win9x;C:\PROGRA~1\MICROS~4\Common\MSDev98\Bin;C:\PROGRA~1\MICROS~4\Common\Tools SET Basemake="C:\Program Files\Microsoft SDK\Include\BKOffice.Mak" SET Bkoffice="C:\Program Files\Microsoft SDK\." SET INCLUDE="C:\Program Files\Microsoft SDK\Include\." SET INETSDK="C:\Program Files\Microsoft SDK\." SET LIB="C:\Program Files\Microsoft SDK\Lib\." SET MSSdk="C:\Program Files\Microsoft SDK\." SET Mstools="C:\Program Files\Microsoft SDK\." Please note that some of the items in the PATH variable may have different short names on each system, depending on the path they've been installed to; they usually are added by VC6 at installation time but I recall there's an option to skip this step so please check. There may be an option to add these system variables from within VC6 but I can't say where exactly - maybe someone else could chime in on this matter. Also please note that not all of the items in the Directory list groups are required in order to correctly compile KernelEx but they may be required for other projects, so it's a good idea to set them up properly right now. If someone more knowledgeable notices anything wrong or missing with my advices, please do correct me. Finally, please do read above in this topic in regard to a few minor issues in the KernelEx project files. Oh and just to be clear: the NSIS packager cannot pack something that has not been compiled, so you definitely have to make VC6 work, compile the whole KernelEx project in batch mode and only after that launch the NSIS packager. The current .nsi script builds the Debug version of KernelEx so all pertaining components should be compiled and available. Using the modified project files I provided in the reply above, should allow a flawless batch compilation of the whole project. Just make sure there's enough free space on that partition. Good luck!

Could you please point to the source of documentation? I'd like to see if there's something useful in there.I should probably get my head back to working on that NE editor, since there's none out there to work (correctly and fully) under 9x, at least in my personal experience. But anyway, it won't do anything other than changing the GUI - no actual code editing. So if there's some unwanted changes from 98SE version to ME version, that'd have to fall into much more capable hands.

DSClient was just a random example, apparently I picked the wrong one. Anyway, unless a certain component has major issues that would need detailed logging, it would be enough to just output "Installing [this component]" before launching an executable and "Finished installing [this component] after it finished, simply by using ECHO. That should be enough to pinpoint which package hangs, crashes or otherwise breaks the installation. If DSClient overwrites newer files, there may be a reason for that. Maybe there's a KB article or something, explaining what it does and why. This way, we might be able to repackage it, editing the inf(s) or whatever to only check for specific file versions and replace under strict conditions. As I mentioned some time ago, I may be able to build a custom installer for the SP, but it would be rather tight unless I find a way to allow modularity and flexibility and for that I'd have to know all the dependecies of all modules, the correct installation sequence and all the internal stuff. That would take quite some time.

No, it doesn't work for me. BTW, you forgot to change the path in the APILIB configuration, which is the latest being built and precisely the one that's being used by all other projects atfterwards. Reason why I insist on leaving the KernelEx.lib versions where they are and just modify the paths in the other projects (kexbasen, kexbases and auxiliary) such that they always use the proper version of KernelEx.lib, whether the projects are compiled in Release, Debug or full batch mode. That solution worked for me everytime, after every commit. I do not know why exactly the copy operation does not work, but since it's not even necessary (at this point), we shouldn't bother with this and just settle on a configuration that works, primarily in 9x and I'm certain it would work in XP/Vista/7 too. Has anyone tried the modified projects from here? Do they work for you as they do for me? Here's some debug logs:

@ Nomen: some of the answers can be found in the readme.txt file included with the Service Pack. In my humble opinion, the SP should be downloaded by every 98SE user, whether they install it or not, because at some point the need may arise and who knows if Internet access will still be available at that point. @ PROBLEMCHYLD: You can always redirect the output of the applications launched by the batch files to the log file. And if there's any operation that does not output anything, you may use @ECHO to send custom text to the log. Please note that if you use single right-angle, the file will be overwritten (previous contents will be lost), whereas if you use double right-angle (as in the example below), text will be appended to the log file. DSCLIENT.EXE /C:"SETUP.EXE /Q:A /R:N" >>LOGFILES.LOG @ECHO Now installing [this file] to [this path] >>LOGFILES.LOG

Thanks for the tip, Xeno. Apparently, _DEBUG is already defined in the .nsi script I got here, so running that command line results in an error. Good thing is, while the command line wouldn't run from within Total Commander, I just modified the Registry, adding a context menu item for building with the Debug switch on, so now it's a breeze choosing Release or Debug with a simple right-click on the .nsi script. But the _DEBUG switch should be removed from the .nsi script, so that building in Release mode would work correctly. REGEDIT4 [HKEY_CLASSES_ROOT\NSIS.Script\shell\compile-debug] @="Compile NSIS Script (Debug)" [HKEY_CLASSES_ROOT\NSIS.Script\shell\compile-debug\command] @="\"C:\\Program Files\\NSIS\\makensisw.exe\" /D_DEBUG \"%1\"" @Leyok: have you ever tried to build the whole project in batch mode on a 9x machine? I see you keep using the Post-build 'copy' command in the Core project, but here on my machine, the KernelEx.lib file is never copied to the destination folder, making kexbasen, kexbases and auxiliary projects fail at link time, not finding ../../common/KernelEx.lib. Moreover, I may be wrong but in my logic, the Debug versions of kexbasen and kexbases should use the Debug version of the KernelEx.lib library, whereas currently, the way the batch order is and considering the copying of the KernelEx.lib library, they would always build through the library create by the APILIB version of the core (if the file would be succesfully copied to the destination folder, that is). I'm not sure of the implications, if any - just saying. Have you tried using the modified project files I linked to somewhere above? They worked perfectly here. I'll be back a little later, after I manage to build, install and test the new version.

That would be great, thank you! And it just occured to me that you might create a second NSIS installer script for a debug package, so that the original Release package would behave normally (being built from the Release branch) while the Debug package (built from the Debug branch) would be the one that creates log and/or sends over pipe.

Ah, that's been a PITA for me, some time ago. Even went as far as mail the authors of some of those utilities (I think HelpNDoc was one of them), asking to fix some quirks that were showing up under 9x, but they wouldn't. Yes, ultimately HTML HelpWorkshop would be the main component that builds the actual .chm, but it's a bit of a challenge to do it manually. I never bothered to learn how to operate it. For building the individual HTML pages that make up the documentation, I'd use Komposer (got two separate versions here, they do work albeit with some minor issues). I think v0.8b3 should work fine in regard to FTP upload, while v0.7.10 has issues with that. Not sure, but it might require KernelEx in order to run. Dunno of other similar tools that'd work under 9x and I did search everywhere, at the time.

@dencorso: Wow, I feel important now! However, for some reason, when splitting posts from other thread, the mail notifications stop coming. I had not received a notification for Leyok's post #6 from March 1 at 3:36PM and if it wasn't for Xeno's reply #7 from March 2 at 11:29 PM (got notification for that), I wouldn't have known the topic has been split. There was no notification for your 1:55AM reply #8 either. Could you please check the notification system (I always set notifications to 'instant')? Thank you. @Xeno86: Sorry about the off-topic in the original topic, it's OK now. And thanks for everything! I might have a serial cable I've used a couple years ago in a project of mine, but I'm not at all familiar with such configuration and it might not even be long enough to connect both machines (can't move them around, there's a whole mess in my room). @Leyok: Could there be an option to print debug to file, as a choice? Thing is, I can't set up a virtual machine and am not familiar with that kind of configuration either. Besides, for the issue at hand, I can access all partitions of the test machine through local network from my main 98SE machine, even when it's stuck at boot time - apparently, the network drivers are already loaded by the time it hangs. Therefore I can open and read a log file, which would be much easier for me. I found out exactly where it hangs by comparing the two versions of bootlog.txt: the one created with KEx 4.5.3 beta and the one created with original KEx 4.5.2. Any other alternative ideas?

I always redownloaded after you made a change, it goes without saying. Also, I either performed Cleaning or deployed it in a separate folder. Latest changes are close to, but not perfect - auxiliary, kexbaseN and kexbaseS still not compiling because of bad path to KernelEx.lib (../../common), which - as I said before - resides in ../../core/Release and ../../core/Debug, respectively. You'll also find an 'Invalid directory' message for the Core projects. I'll be back much later, got some things to attend to, right now. In the mean time, here's the log for a full batch compile: EDIT: I've fixed some of the projects and makefiles, it all compiles fine now as a full batch. Here's the modded files: download EDIT 2: I've installed the package created after compilation, on a test machine (real hardware, 98SE + unofficial SP3) - upon reboot, the boot sequence hangs while Enumerating Plug and Play Software Device Enumerator, right after it finished Enumerating TapeDetection. I managed to uninstall it and then installed the package built from Xeno's last code at Sourceforge - no problems whatsoever after reboot. Machine is an AMD Duron 800MHz with 448MB RAM, SiS630/730 chipset.

- Core depends on kexcrt so it will not compile unless kexcrt is compiled first. - Paths still not fixed in kexbaseN and kexbaseS. prep.exe is being placed in $(WkspDir)\output-i386\Release, while both projects check for an if condition in $(WkspDir)\util\prep\Release and next launch it from the same location, so there's two places to modify for each configuration (Debug and Release), in each project: replace util\prep with output-i386. Also, KernelEx.lib not found in path ../../common, since it's being created in ../../core/Release or ../../core/Debug. Changing the former path in both configurations for both projects fixed it. - Auxiliary fails due to winsta psapi and wtsapi32 makefiles also looking for KernelEx.lib in ../../common. I always did a batch build, it used to work in Xeno's version, only that kexcontrol had to be executed separately, after Core (Debug) and sdbcreate must be disabled since it won't execute under Win9x (I use 98SE). I think the proper order should be (at least for the Release configuration - haven't tried to build Debug): kexcrt prep Core (Debug) kexcontrol Core (APIHOOK) Core (Release) and then all the others. EDIT: The NSIS installer will fail if the Setup folder doesn't exist in output-i386. It should be checked for and created before the executable is built.

Hi there, nice to see the project's been picked up! However, I pulled the zip from your Github repo, tried to compile minutes ago and it won't go all the way. First, the kexbaseN and kexbaseS projects needed a minor path change to retrieve prep.exe from the newly-added folder output-i386. Then, the order the projects are being compiled is not correct, auxiliary will fail because KernelEx.lib is not present, which means dependencies are not correctly set. Finally, the vxd project bails out because of the new vkd.h include that wasn't there in Xeno's original project and is nowhere to be found in VC6, PSDK or 98DDK includes. I extracted MYVKD.H from the Win2k SDK and put in in 98DDK's include folder, but that's not the right thing to do since others may not have/want to use the W2K DDK and even with that header added, the vxd project still throws linker errors. Got no problems whatsoever compiling Xeno's original project, so I doubt it would be my IDE's fault. vxdmain.obj : error LNK2005: "void __stdcall ReplaceLine(int,char *)" (?ReplaceLine@@YGXHPAD@Z) already defined in patch_ifsmgr.obj vxdmain.obj : error LNK2005: "int __stdcall DisplayString(char *)" (?DisplayString@@YGHPAD@Z) already defined in patch_ifsmgr.obj vxdmain.obj : error LNK2005: "int CurrentLine" (?CurrentLine@@3HA) already defined in patch_ifsmgr.obj vxdmain.obj : warning LNK4006: "void __stdcall ReplaceLine(int,char *)" (?ReplaceLine@@YGXHPAD@Z) already defined in patch_ifsmgr.obj; second definition ignored vxdmain.obj : warning LNK4006: "int __stdcall DisplayString(char *)" (?DisplayString@@YGHPAD@Z) already defined in patch_ifsmgr.obj; second definition ignored vxdmain.obj : warning LNK4006: "int CurrentLine" (?CurrentLine@@3HA) already defined in patch_ifsmgr.obj; second definition ignored ../output-i386/Release/VKrnlEx.vxd : fatal error LNK1169: one or more multiply defined symbols found It's understandable that this is a work in progress and errors are inherent. Is there any estimation of the moment when the repository will became stable, that is capable of being compiled? Thank you.

Hey Laser98IX, welcome back! Hope your shoulder's fine now. Guys, here's a new series of colorful banners, hoping they'll match your themes. No gallery for these, they're too many. Just download and look through, maybe you'll find something that fits your tastes. Download banners series 2

Well, what we need most is a whole lotta luck, right now. I don't know much of programming either, when it comes to real languages such as C/C++/C#, Delphi, ASM and so on. I could read and possibly understand portions of code, but not the "full picture", unfortunately. I've been working mostly with AutoHotkey, which is a macro language, interpreter-based, single-threaded, completely unsuitable for kernel-related tasks. I can at most build a few small utilities to aid in programming or daily computer operation, but other than that, I'd leave it to much more knowledgeable people. Thing is, all (or greatest majority) of nowadays' applications are completely disregarding RAM, CPU, storage limitations, considering the new hardware's capabilities. However, us 9x users cannot benefit from newest hardware, but are limited to old one that we can still find drivers for. As such, any software we use should take into account the maximum RAM size (512MB for standard 98SE, 1.15GB or more for ME or R. Loew's patch users), maximum CPU type (instruction sets, speed, number of cores, etc), maximum HDD storage considering the FAT/32 file system and cluster size, maximum USB speed (no USB 3.0+ drivers for 9x) and whatever else I may have omitted here. Since nowadays' software doesn't care about the above, we either need programmers that could build drivers for newest hardware, or programmers that could build a whole new set of applications with regard to the 9x limitations mentioned above. But then, another issue arises: old hardware will eventually fail, spare parts will be hard - and at some point, impossible - to find and with no drivers for new hardware, we will be forced to give up. And personally, I would rather give up internet and computers as a whole, than being just an extension of 'the cloud'. Simple as that!

Maybe he won't, or maybe he's just reading the replies in the mail, without even logging in to the board. And even if he fixed the problem, lost interest or whatever, there may still be other people out there that would benefit from the information in this topic. So I'd say: let the information pile up, for whoever, whenever might need it.

New gallery is up. Full banner archive is here: download Please note first 9 banners were posted as JPG, drastically altering their quality. Details in the package.

Excellent! Now that KernelEx.sdb is in the package, the NSIS installer gets built without a hitch. It's a bit larger though: 229,518 bytes versus original 228,428 bytes. But as it turns out, that's entirely the fault of NSIS (can be seen by opening both original KEx and the newly built one in 7-zip - Packed Size for $PLUGINSDIR is 182,410 vs 181,320). Maybe I should've installed v2.44 instead of 2.46 but that's me: pushing things to the limit. Well, all in all, things went just fine. Where to, now?

Why not present the user with the full banner gallery at installation time, let them pick their preference and patch explorer.exe on the spot? This way we wouldn't have any more complaints (unless they're really picky). Nevermind, I'm drunk - that'd be too much freedom, could go to their head.