BenoitRen

I think you mean different shells for the rendering engine. Yes, there are. Maxthon, Avant, etc. Not a chance. All the vulnerabilities are in the rendering engine. Shells won't change that. SeaMonkey.

This is the Windows 95/98/98SE/ME forum. Please don't give such useless advice.

Here's what I can make out of the patch: Replaces mPeekMessage calls by PeekMessageW calls. Replaces mDispatchMessage calls by DispatchMessageW calls. Pulls out support for Win9x print drivers. For WinNT it's WINSPOOLER, for Win9x it's NULL. It does this by removing the Windows version check and always using WINSPOOLER. Replaces mSHGetPathFromIDList calls by SHGetPathFromIDListW calls. Replaces mSHBrowseForFolder calls by SHBrowseForFolderW calls. Replaces mGetOpenFileName calls by GetOpenFileNameW calls. Replaces mGetSaveFileName calls by GetSaveFileNameW calls. The KeyboardLayout::LoadLayout procedure got modified so that it doesn't compensate anymore for Win9x' inexistant Unicode support. Before, it would use ASCII for Win9x. Removal of ANSI version of a certain procedure in favor of Unicode. Something to do with calling APIs for multiple monitors that are only available on Win98 and Win2000. Implements GetMonitorInfoW in favor of other detection methods. Removes winmm.dll loading, which seems to be used to play back certain sounds. Next it removes all the Win9x support calls that were used before from nsToolkit. Here's parts of it the functions defined: -HMODULE nsToolkit::mShell32Module = NULL; -NS_DefWindowProc nsToolkit::mDefWindowProc = DefWindowProcA; -NS_CallWindowProc nsToolkit::mCallWindowProc = CallWindowProcA; -NS_SetWindowLong nsToolkit::mSetWindowLong = SetWindowLongA; -NS_GetWindowLong nsToolkit::mGetWindowLong = GetWindowLongA; -NS_SendMessage nsToolkit::mSendMessage = nsSendMessage; -NS_DispatchMessage nsToolkit::mDispatchMessage = DispatchMessageA; -NS_GetMessage nsToolkit::mGetMessage = GetMessageA; -NS_PeekMessage nsToolkit::mPeekMessage = PeekMessageA; -NS_GetOpenFileName nsToolkit::mGetOpenFileName = nsGetOpenFileName; -NS_GetSaveFileName nsToolkit::mGetSaveFileName = nsGetSaveFileName; -NS_GetClassName nsToolkit::mGetClassName = nsGetClassName; -NS_CreateWindowEx nsToolkit::mCreateWindowEx = nsCreateWindowEx; -NS_RegisterClass nsToolkit::mRegisterClass = nsRegisterClass; -NS_UnregisterClass nsToolkit::mUnregisterClass = nsUnregisterClass; - // For Windows 9x base OS nsFoo is already pointing to A functions - // However on NT base OS we should point them to respective W functions - nsToolkit::mDefWindowProc = DefWindowProcW; - nsToolkit::mCallWindowProc = CallWindowProcW; - nsToolkit::mSetWindowLong = SetWindowLongW; - nsToolkit::mGetWindowLong = GetWindowLongW; - nsToolkit::mSendMessage = SendMessageW; - nsToolkit::mDispatchMessage = DispatchMessageW; - nsToolkit::mGetMessage = GetMessageW; - nsToolkit::mPeekMessage = PeekMessageW; - nsToolkit::mGetOpenFileName = GetOpenFileNameW; - nsToolkit::mGetSaveFileName = GetSaveFileNameW; - nsToolkit::mGetClassName = GetClassNameW; - nsToolkit::mCreateWindowEx = CreateWindowExW; - nsToolkit::mRegisterClass = RegisterClassW; - nsToolkit::mUnregisterClass = UnregisterClassW; - // Explicit call of SHxxxW in Win95 makes moz fails to run (170969) - // we use GetProcAddress() to hide I guess this is enough food for thought for anyone interested. The patch is huge.

I see, so they ARE different. Hmm, I'll just copy mspaint and wordpad to the Windows folder and change all the references. I don't think I'll delete pbrush and write if they're that small and there for a reason. Thanks for the info!

I have Personal Web Server (from the Win95 CD) and ActivePerl 5 installed. This seemed to work fine, but then I ran into problems when following a tutorial to send cookies to the browser. The cookie never gets stored, and if it does get stored because of some strange hack involving removing a comma (next to "testing", which is bad syntax), it works, but it never has any content. #!perl/bin/ use CGI::Carp qw/fatalsToBrowser/; use strict; use CGI; use CGI::Cookie; my $cgi = new CGI; my $c = new CGI::Cookie(-name => 'different', -value => "testing", -expires => '+1d', -domain => 'localhost'); print "Set-Cookie: $c\n"; print "Content-Type: text/html\n\n"; print $cgi->start_html('Sending cookie'); print $cgi->p('I got your cookie.'); print $cgi->end_html; exit(0); I'm sure the code is correct. I even asked others already. The very first line doesn't matter for a Windows server, by the way. Is this a known problem with PWS? And, since it looks to be a problem with it, is there another small web server that I can install for development purposes that I can point to the Perl libraries? Apache is out, as it will only run on a fully updated Win98 and above system.

Windows 95 installs mspaint.exe and wordpad.exe in C:\Program Files\Accessories, and uses those for the shortcuts in the Start Menu and the file type associations. When you look in C:\Windows, you find pbrush.exe and write.exe, which seem to be the same applications. I checked the version and language, and they're the same as well. Is there a reason for this duplication? Can I safely delete one of both? I'd like to move ones in Accessories to Windows and change the associations and shortcuts accordingly.

Does the free FDISK allow for repartitioning without data loss?

Firefox? I use SeaMonkey. Secured? Right... It's widely known and documented that it's full of security holes.

You're doing the exact opposite of what you should do to not get spyware... And since you're on IE, you're bound to get them, no matter what version. There are many choices. SeaMonkey, K-Meleon, Firefox and Opera. See which one you like best.

Anyone planning on mirroring their older stuff? I'm going to download what I think I might need, but who knows someone is going to need stuff later that won't be there anymore.

I never knew what this did, but now I know! I always wanted a program like this, but I had no idea I already had it.

Network topology: Our home network consists of 1 desktop running Windows 95, one WinXP laptop, and one WinXP desktop. Occasionally my WinXP laptop joins the party. They are all connected by a router which is connected to the Internet. Background: For a long time we have been sending documents via the Internet or via Personal Web Server's FTP service to my Win95 PC to print them. I grew tired of that, and further contributing to the issue was that I didn't have OpenOffice on my PC anymore (too long to load, barely used). So months back I figured I would share the printer that's connected to it. This has worked fine for months, with a hiccup now and then, with one minor detail: my Win95 only rarely saw the other computers. But that didn't cause any issues, so I just shrugged it off. One or two weeks ago we did have an issue on the laptop, which was solved by re-enabling the Computer Browser service (I have played with them in the past, seeking to disable unneeded ones). Issue: Now, however, it's impossible to print from the laptop, and I have no idea what the issue is, as I didn't change anything. The computers are on the same workgroup (WORKGROUP), on the same subnet, the Win95 has Client for Microsoft Networks and NetBUEI installed, binded. On the Win95 PC, when it is the only one on the network, Network Neighbourhood works fine. However, when the laptop joins in, when trying to view Network Neighbourhood, the PC spends an eternity trying to find anything while the pocket light icon animates. Trying to refresh the window doesn't help. Eventually Explorer.exe crashes. Rebooting multiple times and waiting for Win95 to log in to the network didn't help. On the laptop with WinXP, it can see both itself and the Win95 PC. But when I try to print, in Word it tells me that it can't because a setting may be wrong, and in OpenOffice it tells me that I don't have the necessary permissions to access the printer. The user account is not limited, but of that other type that offers more rights, but not as much as the administrator. When trying to access the Win95 PC through Network Neighbourhood, it tells me that I don't have the permission to, and when I try to view its properties, it tells me that it can't find the PC. The printer is listed as a network printer, but it says that it can't find it on its server. I've tried to search for any information on what could be happening on the Internet, but didn't find anything. Help!

I don't need USB except for my scanner. I don't need WiFi here at home.

Just embedding the Trident rendering engine opens you up to IE's horror. A shell won't help you. If you mean "hogs more memory by using two Gecko rendering engines", then I agree. Argh... I just spent several posts explaining that it isn't safe to use at all! Fully updated or not, it doesn't matter. [ulr=http://secunia.com/product/12366/?task=advisories]IE7 is already starting to succumb too. Even better, use K-Meleon! Shells are more than a skin. They are an entire interface that interacts with the backend. No. Here's the list of CSS changes.

Part of the reason why Firefox 2.0 crashes under Windows 95 is that it doesn't understand Unicode. It can help, though I would have to test my theory. Who says I'm using Firefox? I use SeaMonkey, thank you very much. SeaMonkey 1.1 Alpha ran just fine under Windows 95, and I would assume the Beta nightlies do too. People should obsess less about that test. It is not an indication of being standards-compliant. Look it up, Gecko supports 90+% of CSS. That's actually quite good. The Acid2 test was primarily made to show the most common CSS flaws of rendering engines. Considering that most people are going to use thexe Win9x boxes for at least a couple more years, I'd say yes.

D'oh! I forgot that it's also used to indicate something that is left out. Thanks for the links MDGx, I like to learn about things like this.

Well, maybe not at that time, but now I sure do! Though several codecs are really DirectShow filters.

Yup. Flash and Java are plug-ins that generally get installed by the user. I'm not arguing about those. ActiveX is an M$ technology integrated into the browser. No security updates will help it, as its very purpose and functionality makes it insecure. ActiveX grants its control the same priviledges that the user has. It can create, delete, move files at will, and more, just like you can. On a Win9x system, users have all priviledges, making it even more of a threat if one misbehaves. It's better, but it's no safe-guard against IE's own flaws like buffer overflows and such. Not even close. Look at this summary table. HTML is generally well implemented, but IE pales in comparison to other browsers when it comes to CSS (2.1). While other browsers support more than 90% of it, IE6 only knows 51% of it, and IE7 still only knows 57%. An improvement, but not good enough. Especially after 5 years, though I'm aware absolutely no development was done during most of it. And if you use a lot of JavaScript to interact with the DOM as a web developer, IE doesn't give you much meat either, while other browsers do much better. Technically speaking, it's new if it's 2002. I wasn't going to say anything more about it, but since you talk about the problem in your entire post, I'll bite. Apostrophes are generally only used for possessive context. Microsoft's Windows, Mozilla's browser, etc. For plural forms, you never use an apostrophe in English, as far as I know (you do in Dutch, though ).

No, it was not. However, it was the first important browser, in that it was the first browser for Windows, which opened the web to the masses. Not really. Spyglass licensed the technology and trademarks of NCSA Mosaic, but didn't use any of its source code. Later, M$ licensed Spyglass' Mosaic and turned it into Internet Explorer. No, but it was made by some people that worked on NCSA Mosaic before.I got all this from here: http://en.wikipedia.org/wiki/Mosaic_%28web_browser%29 You're not seeing the whole picture. The neglecting of standards by IE also affects you as a user, because it 1) encourages bad web design 2) prohibits web developers from making better web pages because IE has horrible CSS support By the way, please don't abuse the apostrophe. Plural forms don't require one in any context. Sure, you don't, but I bet colour-blind people do. It's an accessibility problem, which is why it didn't become a standard. And pigs fly! IE has frequent updates? Sure, after sitting on the vulnerabilities for up to six months. M$ isn't fast enough as it should be when an exploit is known and in the wild. Mozilla is faster in responding. See, you only get infected if you're using insecure software, of which IE is one, and don't practice common sense. Do I run anti-virus software? No. Do I run anti-malware software? No. Have I been infected? No. Why? Because I use secure Gecko-based browsers while practicing common sense. Most of those sites are geared towards IE. Gecko not being IE, not having ActiveX and generally being secure, doesn't get infected on those sites. And I sure did visit some at times. Who says I'm married? I use SeaMonkey, by the way. The point is that you should use any browser BUT IE to not promote non-standards and be secure.

I have 160 MB of RAM. Would limiting VCache be of any use to me?

The ActiveMovie OCX only lets you play MPEG and AVI files, last I tried. :/

Thanks, I was just browsing your list and looked at the IO.SYS fix entry again, and there was a link to the official fix. Going to apply it now.

That's a lot of files. How big is the full package? I went ahead and started applying the updates I felt were needed. But the Year 2000 update didn't work, because my system is Dutch and the patch is for English Windows. I searched the web, but can't find a place where they still offer it for download. In my search, I found this page, which offers a fix for the conventional memory problem caused by IO.SYS. Is it legitimate? There's only an unofficial patch by MDGx that I know about. EDIT: Solved! Look at this gold mine I found with Google while looking for a Dutch version of the MSGSRV32 fix!

I would stick with 6.4, because it's fast, and the next versions didn't get anything new playback-wise except DRM. I use 6.0 myself, as it doesn't require IE. 6.1 is the last version to not require it, by the way.

ChatZilla rocks. It's easy to use and has no whizbang. It's JavaScript-based, not Java-based, or it'd be REALLY slow.