siria Posted February 10, 2021 Posted February 10, 2021 My 7zip v15.11 on 98SE has no probs with the archived file above.. What I often see is people telling 7z wouldn't work, and never getting the idea their 7z might just be too extremely old. In such cases an update quickly helps (if you have access to updates...)
RainyShadow Posted February 10, 2021 Posted February 10, 2021 (edited) 4 hours ago, CamTron said: 7-zip says it's not a valid archive. Interestingly, I get a different file if I set the Wayback machine to 2000 vs 2008, however, both versions just crash with an invalid instruction when run. I'll just set up a Windows 98 FE VM. It's simpler than tracking down some 20 year old files on the internet. Well, after all, you linked a page which gives 404 for the retail symbols package... This package can be extracted easily (at least in XP) and contains the dibeng.sym file. Edited February 10, 2021 by RainyShadow
SweetLow Posted February 10, 2021 Posted February 10, 2021 (edited) 3 hours ago, RainyShadow said: This package can be extracted easily (at least in XP) and contains the dibeng.sym file. I think this debug kernel: http://web.archive.org/web/20020805200146/http://www.microsoft.com/ddk/download/98/Win98SED.exe is useful too (for debug, of course)... Edited February 10, 2021 by SweetLow typo correction
CamTron Posted February 10, 2021 Author Posted February 10, 2021 What is the difference between the debug and release versions of Windows? I played around with a debug build of Windows 95 once and aside from the build number being displayed on the desktop, I didn't notice any difference.
CamTron Posted February 11, 2021 Author Posted February 11, 2021 (edited) I set up a 98FE virtual machine, converted dibeng.sym to dibeng.nms, and loaded those symbols into SoftICE. However, the stack trace (STACK command) is still just giving me a generic "=> DIBENG(03) at 0367:0FC4 [?]" instead of telling me the actual function name. I'm also unsure of how Windows determines which segment (or selector) a DLL gets mapped to. The crash is happening in segment 0367, but the MOD command shows dibeng.dll loaded at segment 0337. A DLL normally has multiple segments for code and data, as well. Edited February 11, 2021 by CamTron
jumper Posted February 12, 2021 Posted February 12, 2021 (edited) Code Segment CS is executable and has one value. The Stack SS and Data DS/ES Segments are not and usually share a different value. Explorer is an exception where all four are different. See Faultlog.txt or any crash report for examples. Edited February 12, 2021 by jumper
CamTron Posted February 12, 2021 Author Posted February 12, 2021 (edited) Oddly enough, I never seem to get that crash in Windows 95. It only happens in 98. My driver is based on the Windows 95 DDK framebuf sample, so maybe something was changed in Windows 98. I'm currently rewriting it to make the code easier to follow and removing the unused code for old graphics cards like Video7 and ATI Wonder. Edited February 12, 2021 by CamTron
CamTron Posted February 13, 2021 Author Posted February 13, 2021 Is there a way to automatically install a driver (such as through a batch file)? I'd like to automate the process instead of having to go through Device Manager every time I make a change to my code.
MERCURY127 Posted February 13, 2021 Posted February 13, 2021 10 hours ago, CamTron said: every time I make a change to my code. hmm. why just not replace file manually?
SweetLow Posted February 13, 2021 Posted February 13, 2021 13 hours ago, CamTron said: Is there a way to automatically install a driver (such as through a batch file)? find old version of devcon tool
CamTron Posted February 15, 2021 Author Posted February 15, 2021 (edited) I now have a partially functional graphics driver! Source code is included along with a floppy image (install.img) that can be installed in a VM. Please note that this is only compatible with VirtualBox and will not install on any other virtual machine software. Issues: Attempting to open a DOS prompt on Windows 95 will cause a BSOD. It seems to work okay in 98, except for full screen mode not being implemented yet. Hovering over menu items in Windows 95 is glitchy. Attempting to drag a window left or up, or attempting to scroll anything will completely lock up the system. No 2D acceleration yet, so everything is slow. This driver is highly unstable. Expect many random freezes, crashes, and BSODs. The Display properties dialog passes in garbage to my ValidateMode function when trying to determine valid resolutions and bit depths. I've hardcoded 640x480 32-bit color for now. The third bullet point is the most annoying one, and I'm at a roadblock as to figuring out what's causing it. Dragging a window to the left or up immediately hangs the machine. The mouse cursor can move, but nothing can be clicked on or interacted with. SoftICE isn't helping, either. It can detect faults and crashes, but has no way of isolating a freeze. vboxdisp.7z Edited February 16, 2021 by CamTron
MERCURY127 Posted February 16, 2021 Posted February 16, 2021 if not count windbg (aka wdeb386, aka kdbg), there is two more kernel debuggers for 9x - 386SWAT and TRW...
CamTron Posted February 16, 2021 Author Posted February 16, 2021 Good news is I finally solved the freezing issue by adding BANKEDSCAN to the deFlags member of PDEVICE. I'm not entirely sure what caused it, but I suspect it has to do with a string instruction in DIB_BitBlt triggering an endless loop of page faults when trying to copy between video memory banks, since both the source and destination addresses of a string instruction must be mapped at the same time. Anyway, adding a few flags causes the DIB engine to work around the issue. I might switch to using the graphics adapter's linear framebuffer mode in the future. 1
CamTron Posted February 18, 2021 Author Posted February 18, 2021 I managed to solve a few more issues! As of my latest code changes, DOS prompts now switch in and out of fullscreen mode correctly (which is something that even VBEMP has trouble doing), the graphical glitches are gone (caused by stack corruption in one of my functions), and the stability has improved dramatically. I've run into one case where the DDK documentation is WRONG! According to the 95 DDK (and the 98 DDK), the signature for the ValidateMode is: UINT WINAPI ValidateMode(DISPLAYINFO FAR *lpValMode); but in reality, it should be UINT WINAPI ValidateMode(DISPVALMODE FAR *lpValMode); It has this incorrect information in multiple places. While similar in name, the DISPLAYINFO and DISPVALMODE structures have very different layouts, and mixing them up will cause your code not to work as intended. Only by examining the sample code did I figure out that the struct pointer passed in should be DISPVALMODE. 1
CamTron Posted February 19, 2021 Author Posted February 19, 2021 I'm pleased to announce that this driver is approaching a usable state. Here is my new version with many of the aforementioned problems now fixed. Please keep in mind that this is still pre-release alpha software, and is rife with bugs. For testing purposes only. vboxdisp.7z Known bugs in this release: 16-color mode is broken and will result in an unreadable display. Only use this driver with 256 or more colors. Though in reality, you probably want more than 16 colors anyway. Resolutions above 1152x882 may cause the system to crash. Changing color depth in the Display Properties does not take effect unless the machine is restarted. You may occasionally get a message saying "Invalid VxD dynamic link call to device number 3, service B." when rebooting the machine. Switching in and out of full-screen DOS prompts too quickly may visually corrupt some characters. Going into a full-screen DOS prompt while other DOS prompts are on the screen may result in graphical glitches in the full-screen DOS prompt.
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now