BenoitRen

For instance, the EM_GETSELTEXT message needs a buffer that is big enough to store the selected text in. Do I use the EM_EXGETSEL message, and calculate the size of the selection from that, or something?

I can't do better than that. TheGun is coded in Microsoft Assembler, while I'm coding in C. No way I'll be able to make an alternative that small. If anyone else is reading, I'm struggling to implement features. I have a Windows API reference, but it leaves some things to be desired. For most functions I need to allocate an array of chars that is big enough to contain the result. But I don't know how I would poll for the size needed.

I haven't given up on this yet. In fact, I finally started on it. I've already got a basic notepad that can open and save files using the RichEdit control. That's the easy part, I guess.

This is generally not true. Windows 95 is faster than any Linux I've tried. Smaller, depends. But GNU/Linux is not a solution. It requires that you can fiddle with the guts of the system to fix a problem or change anything worthwhile. It's a collection of programs instead of a whole.

Recommended amount of RAM for best performance: Windows 95: 32 MB Windows 98 SE: 64 MB Windows 2000: 256 MB Windows XP: 512 MB I'll take Win9x, thank you very much. All that RAM wasted by the NT editions could be put to much better use.

Not necessarily. With good documentation you can get other programmers to port drivers, while the core team continues working on the actual OS.

This would be when open-source drivers come in.

Well, what is the exception in the DLL? Chances are that it's a missing *W API call to retrieve your home directory, in which case the problem is that the program was compiled in Visual Studio 2008, which doesn't support Win9x (or NT4 for that matter).

Yeah, a lot of NT fanboys on that message board. Still, it was an interesting read. Thanks for the link.

Hey, that's pretty neat! I do have to wonder what the problem is with their machines, though. As old as Windows 95 may be, it's not as problematic as popular opinion would make you think.

Yet another misinformed NT user visited our forum? It never stops. It's not a file system limitation, but an OS one. Win9x uses a 32-bit pointer for HDD addresses. Thanks to LLXX' patch, a 48-bit pointer is used. It's a drive limitation, not a partition one. Partitioning won't solve the problem. Nonsense. This is popular hearsay. Try it yourself, and then come back.

That's Mozilla-based web browsers. And they barely write to the registry. Hell, you can use ZIP builds that don't write to the registry at all, if you want.

Maybe it's time you switched to a better web browser. IE6 is known to be buggy.

Drugwash, ffdshow supports most of those.

Personally I use Windows Media Player 6.0 with ffdshow (the July 2007 version, as the newest one's installer tries to use an API not available in Win95). I've tried VLC before, but WMP 6.0 was snappier.

Then what is the product key? I always believed it was the number on the CoA, which I have to have when I try to install my OEM copy of Windows 95 OSR 2.5.

How many times do I have to repeat this? Those are statistics for one sole website! A website that concerns only a small subset of the web surfing population, namely those actively developing websites.

I don't get it. COA = Certificate of Authority, which is a document with your product key on it. So the product key inputted during installation should have been enough.

The problem is simple: you're using a crappy web browser. IE6 is known to crash a lot.

No, that's already too large. FAT32 gets wasteful at around 30 GB or so.

Everything? Linux and FreeDOS users have the source code. We don't.

Or you can put them inside the cabinet files and change the size in setuppp.inf

For downloading files, yes. For regular Internet surfing, no. Even with broadband, things don't always go fast enough. Servers get slow at times.

I don't think that'd effect it, though a Windows 95 install without IE4 is always better.

As the page says, yes, it will work in Win95 OSR 2.x. What you did should have worked. It's possible that you have to add to the INF file with the device's VID and PID, though.