Drugwash

I second that. It's been years since I disabled the DOS scandisk at startup (from TweakUI, for the interested) and I noticed a major improvement as opposed to old times when it was enabled.However, even the Windows Scandisk (and it seems to be the ME one, IIRC) has some problems - most errors I get when running it are related to MS-DOS mod names being longer than 66 characters. Usually happens in Yahoo profiles, Macromedia Flash Application Data, Java installation foder, .NET Assembly foder. Off-topic anyway. About the DOS games, I think you'd be better off either running them with DOS properties in Windows (\%windir%\DOSSTART.BAT holds the settings) - where you could specify any additional drivers and settings you may need, such as DOS mouse, SoundBlaster settings, CD-ROM, etc - or just dual-boot with plain MS-DOS. I believe running DOS drivers and software in parallel with Windows will just lead to trouble. As for my work, I really wanted to bring an improved installer today, but I went to sleep at 7 AM without being able to figure out a simple file copy issue. Probably registers that don't go to 32bit. Basically it's almost done, just gotta fix that little quirk. And shamefully I still didn't get to even open the code for WBL, as caught as I was with all this. I promise I will as soon as possible, maybe it'll help me fix this last issue too. So... laterz! P.S. Offler, PassingBy's logo uses different coordinates storage addresses and routine, so I guess I'll have to check the code a.s.a.p. and modify LogoTool to allow choosing between the two versions, or just create a separate version of it just for WBL - I'll see what I can come up with.

Honestly I've never seen so much tweaking in those two poor boot files. Only once, for an old mobo, was I forced to use some parameter in CONFIG.SYS - something like /M:6 or so, can't remember exactly - otherwise everything was almost stock. There might have been some minor tweaks at times, while playing with different tweaking tools. For comparison, here's my files on the main machine: Autoexec.bat: Config.sys: There are some tweaks in MSDOS.SYS though. Here you are: MSDOS.SYS: I've seen something in your files that I was afraid of: Windows folder not called 'Windows' as usual but 'OS'. That's gonna negatively impact the Patcher, as it's not yet flexible to accept custom path/name to the Windows folder. Actually this is something I was gonna work on next and I see there's good reason to. However, I'd be interested in seeing if you get the error message regarding the Windows folder not being found. The Patcher will abort the current operation if any of IO.SYS, COMMAND.COM, Windows folder are not found, so no files would be patched/installed/deleted in this case. Now on my side, today I've had one of these days again. The spare monitor wouldn't start up anymore, the second test machine (Win95B) wouldn't recognize the old HP D2826 monitor, then when I managed to install the driver it would stay blank on reboot because it didn't like the 'Adapter default' refresh rate and I had to boot in safe mode and switch to 'Optimal', then installing a second videocard (S3 Trio64V2/DX) to see if the logo animation shows up. I had trouble installing its driver, then the resolution wouldn't go up to 1024x768 as it was because of only 1MB of video memory and so on. When I finally managed to get it running the animation showed up properly, no freeze. Under Windows, I tried Patcher on it and... it wouldn't work. Said it couldn't find \IO.SYS and \COMMAND.COM. Tried to put Patcher in any possible folder (C:\Windows, C:\ root) but no dice. Rebooted in DOS mode - no keyboard. I went for the hammer as I had an urge to smash it into pieces, but reason prevailed (fortunately). Went into BIOS, tried a few settings blindly, until I found I had to disable USB keyboard support to have a working AT keyboard in DOS. Oh, forgot to mention the stupid BIOS revision where I had to choose 'System keyboard: Absent', otherwise I'd get that classic moronic error: Keyboard error - Press F1 to resume. Now, after I got a keyboard in DOS, I tried Patcher again and... again it wouldn't work - same error. So now I'm wondering what is the difference between the 2 machines that it works fine with and this one where it doesn't. I'm only using INT10h and INT21h for checking those files' presence. I don't think it could be something CPU-related (Pentium P54C 166MHz - no MMX). Maybe the DOS version in Win95... Anyway, I need to work that out and also check PassingBy's 'baby' so enough blabbering. [EDIT] Actually this was an easy one: MSDOS.SYS had arhs attributes and could not be opened to read. Fixed it and improved so it preventively removes and then brings back all involved files' attributes. Patcher works now in Win95B too. Now gotta debug the debug routine that was showing wrong messages.

I'm using DSClock for that purpose on Win98SE, since TClock has issues on such systems anyway.

No problem, I hope you manage to fix it soon. My work on WLL itself has stalled for a while since I'm working on the installer. It's almost ready, just got a few pointers to fix as it's patching at wrong addresses. Then I'll have to improve the copy routine so it wouldn't use that large buffer I allocated currently and maybe add some options, like Install/Reinstall/Uninstall. I wish this toothache would gimme a break... [EDIT] Guess I got lucky. Here's the first BETA DEBUG version of the installer/unistaller. For now it's called Patcher, as it sounded more appropriate. I'm curious if any AV would pick it as a virus or something, considering it patches files. Momentarily, on installation it only patches IO.SYS & COMMAND.COM and copies WLL.COM to %windir%. For this, WLL.COM has to be in the same folder as Patcher. It does not (yet) copy any LOGO.SYS to C:, so that should be done manually, preferrably backing up the old LOGO.SYS first. The uninstall is pretty straightforward too: patches the files back and deletes WLL.COM from %windir%. It does not create any backups so be extremely careful when trying it. Better back up IO.SYS and COMMAND.COM before hand, in case anything goes wrong. It has been tested on my both Win98SE machines - no test on Win95 yet, I am too tired. Any feedback would be appreciated (except for "ugh, ugly code" - I know that already ) [attachment removed - newer version below]

I think I managed to put together a universal installer. I haven't tested it yet - just partly ran it through the debugger. I'm dead tired, so I'll go to sleep now and test it on the spare machine later when I wake up. It doesn't yet ask anything, just does its job: installs if WLL.COM is not present in %windir%, otherwise removes WLL.COM and patches IO.SYS and COMMAND.COM to their normal strings. It prints a lot of debug info though.

Dunno why one would launch WLL under Windows, but it may happen in DOS mode too. And the problem was that I wanted to use the said routine in the (un)installer, which would usually run under Windows, at least at install time. Anyway, I totally scrapped that routine and created another one that reads MSDOS.SYS - this one seems to work fine under Windows, but I'm extremely tired now and can't test in DOS mode. There's only one tiny issue that keeps me from advancing: a parity check wouldn't work. The routine is as follows (snippet): Well, the last test instruction wouldn't test parity, it returns zero; first one works OK. The pres variable is 1Fh at the moment of testing, checked in debugger.Well, gotta go to sleep now - I took some pills that close my eyes against my will. Laterz! [EDIT] Scrap that, I replaced with: bt pres,4 jnc instwll and everything's fine now. Weird coding...

No, they need to be patched. I'm working on such patcher but I'm hindered by some stubborn code, added to my lack of knowledge. You may however do as alexanrs mentioned above. I have used the XVI32 editor for this job. Yes, this happens under Windows. I have copy/pasted the respective procedure (with all associated variables and stuff) and on running the compiled file a lot of times subsequently, it sometimes yielded the right result and other times I'd get 'Windows folder not found' (that was a debug string display).I never understood what exactly that routine is meant to do anyway, except for searching for some wininit.ini file, which is not present on my computer. I guess there has to be some other way of getting the working WinDir - I was thinking of MSDOS.SYS, as it contains WinBootDir=C:\Windows; would it be OK to use it or would there be problems with multiboot environments, virtual machines and such? I can't test such complex configurations here on my limited hardware. I would have done this patcher in AutoHotkey just like LogoTool, but the uninstall should work in pure DOS mode, should anything bad happen preventing Windows from booting.

My WLL has always been synced with Tihiy's and it's obviously based on his code. You may compare the scripts if you want. However, I have added a lot of code for the progressbar coordinates feature and the last version above has an extra loop trying to catch the freezing bug. Please note that the IO.SYS and COMMAND.COM found in the package are for English version of Win98SE (4.10.2222A). I am currently working on a universal installer for any version of Windows 95 and 98 (not sure if ME is worth the bother) so each system will keep its original files, which will be patched in place. You may wanna replace the English files with the Slovak (sorry for the earlier mistake) ones from Tihiy's RP7 package, files that are already patched for use with WLL. Please test the above version of WLL.COM and tell me if freezing still occurs and if the rate is the same as before or not (how many freezes in how many boot attempts).

I need a drink, maybe that would help me understand something... 1. SVGACOM DOES NOT BOOT INTO WINDOWS! WLL does! So if you think that copying SVGACOM.COM to C: or C:\Windows would make the system boot with it, you're completely wrong. It will still use the current WLL.COM in C:\Windows and any errors you receive will be due to that module, not SVGACOM. 2. SVGACOM ONLY TESTS THE ANIMATION ROUTINE! This is useful for logo creators and/or code debuggers. 3. CORRECT WAY OF TESTING SVGACOM: a ) Testing in DOS mode: - boot into DOS mode (press F8 during boot -> Command prompt only) - go to SVGACOM's directory and start SVGACOM.COM - observe its behavior; let it animate for as long as you like (if it does display anything, that is) - press a key to exit animation - repeat the above steps in a ) for as many times as you like Please note that testing under Windows is not absolutely necessary - it's just for convenience, in case you change something in the code or in your logo bitmap and wanna see the result. As the code is meant to run in DOS mode at boot time, any errors while running it under Windows are not much relevant, unless it screws Windows up badly. b ) Testing under Windows: - boot into Windows normally but try not to start any applications except strictly necessary ones; resident antivirus or similar services should temporarily be disabled - go to SVGACOM's folder and start SVGACOM.COM - observe its behavior; let it animate for as long as you like (if it does display anything, that is) - press a key to exit animation - note any abnormal behavior afterwards, such as video corruption, hangs, instant reboots (God forbid), etc. - if everything goes well, repeat the above steps in b ) for as many times as you like Below there's a test version of the WLL code - everything else is unchanged from the previous version posted above. I have added a loop that checks for the Windows directory for a maximum of 50 times after which it bails out. If it won't find the directory or will find the reference to it in a wrong place (that's what I suspect), the usual freeze will occur. Later on I may add some more debugging code, to see where exactly the freeze occurs. I might need some help for the correct understanding of the FindWin procedure. Test version of WLL.COM

It would help if you downloaded my pack above and read the readme files carefully. It is explained - and I said that through this thread too - that SVGACOM.COM is just the animation part of WLL.COM and is intended solely for the purpose of testing the animation routine that I have slightly modified regarding progressbar coordinates' source. SVGACOM.COM can be run in Windows mode or in DOS mode, manually, but it will not do anything else but display the animated logo. On a keypress, it will exit. That's all. When testing it under Windows, please do so right after a fresh reboot, as in some rare cases it may corrupt the video memory, after some other applications have run - I couldn't find a pattern here, as it only happened to me twice in all the tests I've performed. In my package there is also a fully working WLL.COM, based on my version of SVGACOM.COM, with Tihiy's latest timer changes added in. I have this version installed on my main machine. Also there is LogoTool, a neat little application written in AutoHotkey (the AH script is included, of course), that allows one to quickly patch their bitmaps with the progressbar coordinates, to make it work with my version of SVGACOM/WLL. They all need testing, otherwise I'm working in vain here. [EDIT] While working on the installer, I noticed a weird instability in the FindWin procedure. I copied it entirely from WLL only with minor changes to a couple of labels. While testing under Windows, it would randomly fail. As the respective code is not implemented yet, I put text display instead of the install and uninstall routines and while running the very same compiled code a few times in a row, I would sometimes get 'Uninstall succesful' and sometimes 'Couldn't find the Windows folder'. I wonder how could the very same file yield different results when run a few subsequent times in the same environment? Could this be the reason for the random hangs at startup with WLL?

Offler, it would be useful if you could specify which WLL version you're testing and which are you having troubles with. Tihiy's version has a small buffer value (512 bytes) while mine takes 2048 (2kB) and also has extra code related to the animation routine. Any of those differences may lead to different behavior on certain machines. On another note, I've had no feedback related to LogoTool: did anyone test it yet? Is it working correctly? Any bugs or feature requests? Oh and to my shame , I've always forgot to mention that the LogoTool idea is entirely holli's so I think he should get the deserved credit for it. Thank you very much holli for the excellent idea! I hope you like LogoTool! I'm still considering the palette storage for the coordinates, but I first wanted to have the animation routines and LogoTool established and working - changes can be made afterwards, if palette usage is proven harmless.

Kinda off-topic but related to your issue, I could confirm that certain applications/drivers/etc. at install time may be searching for %windir% to deploy some of their files and in doing that, they're probably searching for specific Windows file(s). When the Windows installation kit (clear copy of the CD-ROM) is found on the (active) drive, it probably contains the respective file(s), which tricks those applications into thinking that they found %windir%, so they deploy their files there instead of the real %windir% folder. I've had such behavior with my Lexmark 1150 combo while having the Win98SE kit on drive C: for testing the UBCD project, when I found dozens of Lexmark-related files in the Win98 folder, wondering how they ended up in there. Basically what I'm saying is that some original Windows installation file may be overwritten by other from another application while the kit is on the HDD, so it'd be recommended for the Windows installation kit to be zipped or saved as an ISO image, mountable in Daemon Tools, Nero Virtual Drive, etc. or quickly browsable through Total Commander's ISO plug-in or similar.

The animation routine still has its quirks, apparently. I've had a crash too in SVGACOM today, although I haven't changed anything in that routine since last time. Happened under Windows, on my main machine, after I had run certain applications. However, after a reboot, I started it again and it worked correctly. Offler, I tested LogoTool on your bitmap - it's a jewel. And heck, I managed to fix the not-updating edit boxes. So - while there's no major change in WLL code today (apart from fixing a missing registry restore)... I present you WLL.COM with the improved LogoTool v1.0.1.0 (this package contains SVGACOM too). Tihiy, I'm working on the WLL installer/uninstaller.

I've seen Intel LAN drivers. They indeed have a lot of settings available, more than the average Joe would ever be able to handle. However, I believe them as being about the same settings that these optimizers are tweaking, for NICs that do not have a GUI for user-customizable options. At first run after a vanilla Windows setup, TZ Connection Booster will show all options as 'have not been set', which means the drivers go for some default values or they're not even initialized. The program offers the default values, which can be manually altered by knowledgeable users. What this program doesn't do is set TTL to a user-defined value and that is why I use TCP Optimizer after it. It will set TTL to 64 and also other settings that I never bothered to check for, as long as everything went just fine after the tweaks. In fact, my connection might just be too slow for the values I've chosen. As a matter of fact, eMule is the most stable application I've used. Compared to my browser that eats 35-40% of the resources and a fully customized Miranda IM that eats about the same, eMule is a mere child. Apart from the exit issue, I haven't seen it crash since a few versions ago. Apologies, we're going off-topic already.

This happens to me too, especially after I 'optimized' the network connection with TZ Connection Booster and TCP Optimizer. And yes, I do have a VIA chipset myself on this mobo. But I found a not-so-elegant solution to work this around: I disconnect eMule, start SysInternals' TCPView, quickly select all connections and shut them down forcibly. There will be some new connections in the mean time, but the system can manage them gracefully. And so I avoid the BSOD. Otherwise eMule works just fine in Win98, just needs MSLU. IIRC, I also posted in the eMule board about this issue. Ornis sent a newsletter to translators around X-Mas or so (I'm maintaining Romanian translation in official eMule), saying there will be a new version soon, but nothing showed up since.

This is strange, because I've tested it 1 minute ago under Windows98SE English, with 18% free System/GDI resources, SlimBrowser, Miranda IM, Metapad, XVI32 all running and it worked just fine, without a glitch. I'll perform some more testing tomorrow on the other machine. Still you haven't offered any information on your hardware that could help diagnosing the issues. Perfect timing... should I keep wasting my time on what I've developed so far so should I just scrap it?[EDIT] Links removed. File is available for download further on in this thread. [/EDIT] I'm very tired any probably not thinking very clear at the moment.

Thank you for reporting! Issue fixed. Please download this version: SVGACOM with LogoTool Changelog: - added automatic string centering for 'Press a key to exit...' - rearranged centering routine into a procedure - removed superfluous file close Please tell me if there's any more problems. P.S: If you find my test bootscreen ugly, I'll be waiting to see one created by you. After all, that's why I put all this work into this code: to allow everyone unleash their creativity.

Please reread the edited post above. SVGACOM cannot be run instead of WLL, as it lacks the code that calls the startup of Windows. So Windows will never start with it, because it can't. SVGACOM is only part of WLL, intended for animation tests only. I only intend to post the whole WLL code when I would have rendered it as foulproof as possible. Got a working version here for personal use but it still has the same quirks that SVGACOM has. Regarding the garbled error messages, there's not much info you offered me so I'm not sure where to start searching for faults. I'll investigate the issue though. One thing you could do is open SVGACOM.ASM, scroll to the end of file until you find the string definitions, and replace the text with something shorter and/or use some special characters (please don't remove the dollar sign ($) at the end of the string), compile the code and test it, both in DOS mode and under Windows (make sure the logo bitmap is not there, so you can actually get the error message). Tell me how it went. Obviously, since the code contains a wait for a keypress to exit. WLL instead contains a timer that allows execution of other modules during the animation.

That's why there's an already compiled SVGACOM.COM in the package: for people that can't/won't spend time compiling. The ASM file is there just for those who wouldn't trust a precompiled file. That's what I need to find out and fix. You'll have to offer me details about your hardware and software environment you've been testing it with. The message should be very clear, in English and read either File C:\LOGO.SYS is not present or File C:\LOGO.SYS size mismatch, followed by Press a key to start Windows... a few lines below.(In the version posted below I have changed the error messages to reflect the real name of the required file for this testing version of the code) That would be the standard message that should display with a WLL standard installation. However, in case of SVGACOM, the name of the file that it's looking for is not LOGO.SYS, but startup.bmp. I intentionally shipped the last 2 versions of SVGACOM with a renamed bitmap file, so a distracted user would get the error message at first run and attempt to fix the problem. My bad is that I forgot to mention the real name that the bitmap should bear. If you got anything else but one of the above 2 messages, please describe what you saw and/or post a screenshot if possible. OK, so first of all you can run SVGACOM in Windows too, there should be no problem. Then, as I mentioned above, the name of the test logo file should be startup.bmp. Just place SVGACOM.COM and startup.bmp together in the same folder and run SVGACOM.COM - the logo should be displayed. If it does, please tell me if you notice anything unusual in the animation shaft or at the bitmap itself. If there's any error, please describe as accurate as possible. SVGACOM cannot replace WLL. It is intended solely as a test for the animation itself and does not contain the necessary routines to start up Windows, so replacing WLL with SVGACOM will only result in Windows being unable to boot.One last consideration: LogoTool will ask to save the file as LOGO.SYS, for maximum convenience for when WLL.COM will be released. However, as mentioned above, the SVGACOM code requires the file to be named as startup.bmp, so please make sure you save your file as startup.bmp, for now. For the time being, do not overwrite your current LOGO.SYS in the C:\ folder with the one saved by LogoTool. I hope the information above will be helpful. Thank you for testing, so far! Here is the latest version of SVGACOM, with fixed error messages and improved readme. I have packed LogoTool together with it and also added a readme for it. Enjoy! [EDIT] Link removed. File is available for download further on in this thread. [/EDIT]

OK, time for some more playin' around. I see a lot of interest in this project - 5 downloads, whoa! - and also lots of feedback... not. Oh well, nobody's gonna die from that. It's just that the last version of SVGACOM wasn't performing very well, at least not when patched into the actual WLL code. So I had to change a few things, mainly internal subroutine positioning and handling. It worked fine on my main machine and the 200MHz test one. Still, I'm not gonna publish the WLL code for now as it lacks a few things and the final position of the parameters inside the bitmap has not been decided yet. However, I have created a first version of a bitmap logo patcher, using the current parameter positioning. So I give you the latest SVGACOM version and introducing LogoTool. They should work fine with each other, but please calculate progressbar position and size so it would not cross between video banks, otherwise the animation would appear corrupt. This is the protection I didn't yet manage to put in place and the main reason I'm holding back the WLL release. [EDIT] I have removed links to the respective version of SVGACOM. Please use the latest available further on in the thread. LogoTool is included within the SVGACOM package.

I haven't seen your system specific's IO.SYS and COMMAND.COM attached in the 'WLL fixes...' thread. I intend to create a universal patcher but I need all possible samples so I can find a pattern. At the moment I have a working WLL, however protection is still not perfect and badly chosen coordinates can lead to a corrupt screen and animation. Tonight I have also finished first version of a LOGO.SYS patcher - no need to hexedit your bitmap, the tool will do it for you, as elegantly as possible. I'd be happy if you could test them both and offer some much needed feedback.

I believe so. My card's chipset is CL-GD5446-V. You may contact me directly to send those files, if you want; I'm online now.

You will, as soon as you fix the error by simply copying the correct LOGO.SYS to C:\. I'd do it for you, but I can't, so I just force you to do it yourself. See how stubborn I am? I'm afraid I cannot test QEMU or any other kind of virtual machine here, because my most powerful machine is a 400MHz Pentium II that runs exclusively on Win98SE, while the other 2 are 166 and 200 MHz respectively, the former with Win95B and the latter with Win98SE (that was my primary machine until Nov 2006). However I believe that the display corruption could be QEMU's issue, since the code works fine on my 400 and 200 MHz machines. The one with Win95 has a 2MB PCI CirrusLogic videocard and also displays a corrupt logo (all image is 'packed' into the first video bank) but I considered it a videocard issue, probably no/bad VESA implementation. I left this investigation for a later time.

Current logic is:- if you bother to install WLL is because most of the times you're in front of the PC and want to see a nice logo - if you don't see the logo you wanted and you don't get a comprehensive explanation for that, you'll get p***ed off and start posting around - if you do get the explanation, most likely you'll fix the error and you'll never be bothered by the message again - if you're not in front of the PC at boot time, you don't need WLL because you're not gonna see any logo anyway Well, this apart, seems that the new code kinda borked WLL. While it works in SVGACOM, when applied to WLL makes it hang after the animation. I found that the hard way, when this morning my machine wouldn't boot anymore - backups to the rescue. So now I got even more on my plate. I'll worry about minor details later.

Why wanna do the work twice? Please have a look into the uncompressed RP7 package. You'll find the folder "logo" in it. Open it and you'll see some subfolders like 1031 (english), 1033 (german), ... containing IO.SYS and COMMAND.COM for various languages. Because there's no patched IO.SYS and COMMAND.COM for Win95, Win98Gold and WinME. I see no reason why those systems couldn't benefit from this animated logo. Yes, but you don't see the error message or it disappears too fast for reading. If something wrong with the logo, it would be better none is displayed. It doesn't dissapear if it waits for a keypress. I'm happy about you like my idea. This tool don't have to be programmed in assembler. E.g. you can use C, C++, Turbo Pascal, Delphi or any other language you like. I'm worry about not being a programmer. But please, give the unused bytes in the palette area a try...thanks for your work! I'm as much a programmer as you are. Maybe just a bit more stubborn. Dunno any of the above-mentioned languages and to be honest, I'd never be able to learn any of them. I've been lurking around C programmers for a few years and I couldn't get anything of it into my head - ASM is just the reminiscent of my old playing with Z80 code. Now, regarding the code at hand... I've added some protection but it's not 100% foulproof. Then, I realized the buffer cannot be bigger than 32768 bytes or corruption will occur. And finally, the cross-bank bullet is gonna be a pain in the arse - my brains are close to a shortcircuit already. EDIT] Link removed. File is available for download further on in this thread.