BenoitRen

You implicitly seemed to by disagreeing with my claim that Windows 95's shell is best. I never found any advantage in having those icons there taking away estate from task buttons when they were readily available in the Start Menu, alphabetically and clearly categorised. Those tooltips that almost immediately pop up when hovering above them annoy me as well.

And blackbox and progman do? Also, it's a taskbar, showing the running applications. Those toolbars have no place there.

Windows 95's shell is even better than those three.

Actually, I tested this, and it doesn't. Again, this is what I was doing in the first place! Everything was forwarded to DefWindowProc. I only tried to catch the WM_CONTEXTMENU message, which I never got. The RichEdit control isn't acting funny anymore, by the way. Weird. EDIT: Actually, it still is. Depends on the file. My main menu is now a resource. The context menu appears at the right place now, too!

But as I already said, it doesn't work for what I want to do!

Thanks Mijzelf. I've taken approach 2. It seems to be the most efficient. I've also improved my message loop. Now how can I have the context menu appear with the top left corner on the place my mouse is pointing at? It appears either above or to the left now. The RichEdit control has some weird behaviour. It doesn't show the horizontal scroll bar until I start typing. All the appropriate flags are set, though. Yes. Would this be more efficient? Don't know what to make of this IME stuff. As far as I know, on Win9x, it's an IE module. Refreshed source file.

It doesn't all have to be supported stuff. For example, I still use the good old WS_FTP LE for Windows 95 that works fairly well without any issues.

IME? No, it's just a notepad. I don't think I subclassed my RichEdit control, as I don't even know what that means. EDIT: I looked it up after posting this message. However, my context menu still doesn't work. I don't seem to get the WM_CONTEXTMENU message either. I've verified that the new window procedure is called, though (which caused a stack error after lots of message boxes popping up...). My code.

I've been too lazy to do Search and Replace, so I've been doing other little things, like focusing the RichEdit, making it remember the file filter, and adding keyboard shortcuts. Now I want to add a context menu. However, it's not working. I never receive a WM_CONTEXTMENU message when I right-click in the RichEdit. I've got all the rest figured out: call TrackPopupMenu with the menu handle using the parameters of the WM_CONTEXTMENU message. Any ideas?

Nope. We have such an outdated machine with 128 MB here. Doesn't perform as well as my own outdated machine running Windows 95 that has a weaker CPU.

Windows 95 can be installed and used without IE. The shell is a lot less annoying and cluttered. AndrewT sums it up well in his weblog post about Windows 95. Such differences are hardly just a Service Pack.

Running GNU/Linux on an old computer isn't that great. First-hand experience, here. And the computer isn't even a 486. I'm talking about running it with a GUI environment, of course. For that, Windows is much faster. Consider that my computer, with a Pentium II 233 Mhz, was barely considered suitable for Linux with a GUI when it runs Windows 95 perfectly. There are plenty of people who don't switch to Linux because they're PC gamers. If they like Linux enough, they'll dual-boot, but that's obviously not a switch. Wine often isn't an option for them, as it's not that good yet for games released within the past 5 years or so.

Wow, 3.1? And I thought the Borland we were using at my college was old (4.52).

I don't doubt Win9x has protected mode, but I have to admit it's not as good as other operatings systems'. Just the other day I was testing some new code in my notepad replacement, and I got caught in a blue screen of death loop, forcing me to reboot. This kind of situation doesn't happen often, mainly because the programs I use behave, but rogue programs can take out the system or suck up all the resources (like GAIM 0.73 did for me, ugh). Hear, hear.

DOSBox is quite slow compared to the real thing, so I wouldn't say DOSBox makes it less of an issue.

Indeed, it doesn't matter if you program in Borland C++ or or Microsoft Visual C++. Write in whatever you like. I wouldn't use minGW on Windows as a compiler, though. It's not adequate on that platform. If you want a free C++ compiler, get Borland's free command line tools.

I'd rather not have MSVC8 DLLs at all on my machine. I'll get by without an IDE for now. I implemented "Go To Line" and "Save"! Save was a bit tricky, since it involved a string, which always needs special treatment. I used a global string to keep the file name of the opened file, and I NULL the first char when I do "New". Seems to work well! I would have preferred to avoid using the string library, though. Anyway, my notepad alternative is now good enough for basic editing, so I'll be using it to edit the program's own source code. How cool is that! Next, Search and Replace!

You'd be surprised. On its own it's a good thing, but when you look at the bigger picture, it's not. The reason they have to maintain compatibility in the first place is because every few years they push a new Windows release and end-of-life the previous one in a couple years. So you end up with people buying brand new Windows XP boxes to run some old Windows 95 program. It's silly.

All right! I got my search dialog to work! Here's what I did. I changed the CONTROLs that were defined as checkboxes to CHECKBOX, and the CONTROLs defined as radio buttons to RADIOBUTTON. I forgot to change DIALOG to DIALOGEX, it seems, but it worked either way. Yay!

I put some MessageBox calls in WM_COMMAND to figure out if these things were even getting called. Turns out they do. As for the size, Borland C++ 4.52 uses the Borland C++ runtime to achieve a smaller size. I noticed this by using Dependency Walker. The open and save dialogs work now! I looked at the page of theForger's tutorial that dealed with them, and it looks like I needed to use OPENFILENAME_SIZE_VERSION_400 instead of sizeof(ofn) when specifying the size of the OPENFILENAME struct. Whew! My search dialog still isn't working, though. What's more, it only works in my program compiled with Borland C++ 4.52 when the IDE is running! Crazy stuff.

Because most people are using 98SE. I'm only one of the few still using 95. That's okay, though, there isn't much I need.

The examples of theForger don't show open/save dialogs either. I ran Dependency Walker on one of them, and it looks for Borland32 in KERNEL32.DLL. It's the same thing with my compiled program. This is weird.

I managed to compile my resource and my program with the command line tools. But now no dialog works! Not my own, nor an open or save as dialog. I've tried leaving out the resource. Doesn't make any difference. What's also weird is that the size of the exe output by the compiler is 50 kB, versus the 29 kB one output by Borland C++ 4.52. The problems keep piling up. I now added the path to the bin directory to the path environment variable, and whenever I try to compile now I get "Response file not allowed here.". Google doesn't have anything to say about that.

Got Borland C++ Compiler 5.5 after jumping through registration hoops. And then I found out that Visual Windows has a version with it included. Oops. Installed Visual Windows, and on start-up it complains about missing KERNEL32.DLL:GetLongPathNameW in a MSVC 8.0 DLL. So the website lies!

I use Windows 95, you insensitive clod!