Sephiroth wrote:

One of you stated in the prior thread that a Dell application was preventing it from coming on at all, but by closing that application the screensaver would kick in while windowed.

I said, that I had a problem with getting the screensaver to kick in when I had the Dell utility running in the systray and DOSBox running windowed. Once I exited the Dell utility, the screensaver behaved as per expectation. I guess the Dell utility does not react to me changing the screensaver timeout from the desktop and overrides the settings with its own values.

Once the Dell utility was exited, this is what I saw:

It would activate after 1 minute when DOSBox was running windowed.

It would NOT activate after 1 minute when DOSBox was running fullscreen.

And - curious enough - it would NOT activate if I flipped DOSBox from windowed to fullscreen and back to windowed again. Something in DOSBox/SDL process apparently sets a flag or something that prevents the screensaver from activating. If I exited DOSBox (and the process terminated) then the screensaver would again (as expected) kick in.

So if I have a problem it is with getting the screensaver to activate while in windowed mode on my home PC - but that is contrary to your problem!

On my work PC, the screensaver worked as expected. Kicking in when running windowed, and never when running fullscreen.

So what's the conclusion? That it's a simple dosbox bug or what?

It's something in the three or four applications I tested that exhibited this behavior. DOSBox is one, and I honestly cannot remember the other three, but I mentioned one or two of them on another thread. Either way, over a hundred apps now tested and only those few had the behavior while the rest worked. If it was an SDL issue, I would assume that all of the apps would mess up at one point or another, but none ever did. I tested each app for varying amounts of time at least four times. If this IS an SDL bug, which it may evry well be, something in these apps is triggering it, but I have no clue what.

Oh and I wasn't looking for CDROM functions, just problems with their CDROM support. Didn't find any mention of it, but now that you explained that it is completely missing from SDL, that may be why. I won't bother with that bug since it's a feature that isn't here yet.

If it was an SDL issue, I would assume that all of the apps would mess up

Bad assumption. But of course you'll only know it after you debugged it, so keep us informed!
Sadly i can't be of any help as it doesn't happen for me.

Like I said, it may be a very obscure bug in SDL, but it is only being triggered by a few applications, meaning that those applications may not be bugged themselves, but may be manipulating SDL in just the right way to trigger this occurrence. I won't be debugging it though, as I have very little time for much of anything right now. College is starting back, I am restoring a 1953 Chevy 3100 Pickup, and I play Guild Wars in the evenings for an hour several nights a week. I really need to release my front-end for DOSBox as well.

I won't be debugging it though, as I have very little time for much of anything right now.

Ah, you seem to have enough time to post certain topics to death. Instead of constantly nagging, do what wd said: try to debug the "bug" (if it is one), and supply detailed information. That would be much more efficient and helpful than what you're doing now.

It's not my place to fix somebody else's program. This goes for SDL and for DOSBox, as well as the other two or three apps that exhibit this behavior. I have time to post while working, and thanks to the use of tabs in Firefox, I can open my regular forums in tabs and simply click on those tabs every so often and hit F5 to refresh. Common thing in this day and time. Either way, I'd much rather work on my own projects or earn money than solve a problem with one of two applications (SDL or DOSBox) which would net me nothing but a big fix for a program I use semi-regularly.

Also, since this bug does not crash the program, it would be insanely difficult to locate, I'd think. In fact the only way I'd know to discover what is causing it, is to go over the code, line by line, and alter things that looked suspicious, then recompile and test. I may do that, but not right now. If I do get some time and do it, I will post any fixes I find.

*EDIT*

I didn't see a handle for the WM_SCREENSAVE event (or the SDL equivalent) in "sdlmain.cpp" so I did a search for SDL screensaver information and came across a few threads like the one below. What version of SDL does 0.72 use, because this may be the bug mentioned in the thread below. A patch for SDL is listed in the second link.

http://listas.apesol.org/pipermail/sdl-libsdl … ber/040094.html
http://listas.apesol.org/pipermail/sdl-libsdl … ber/038163.html

because this may be the bug mentioned in the thread below.

No. The bug report+fix is from 2003, the version we used is far later, 1.2.12 or so.
The exact version is in the dll (rightclick/properties).

It's not my place to fix somebody else's program.

So we're back at screensaver stuff in the cdrom volume thread?
I'm not about to fix somebody else's unreproducable problems that are
said to happen on "all" systems whereas IF it's a bug it's not caused by dosbox.

I'll get my camcorder and take it to work along with DOSBox on my thumb-drive. I figure fifty or so consecutive instances should say something. Again, this may not be a bug with DOSBox itself, but rather DOSBox does something with SDL that causes SDL to do this on the more powerful, custom systems with real soundcards and higher-end video cards, as well as without that custom power-management software that prebuilt systems come with. I'll probably spend a few minutes tinkering with it tonight, but the easiest test I could imagine would be to add support for the SDL messages about screensaver and power saver, and return zero for them. If that fixes it, then that proves that for some unknown reason, DOSBox is telling SDL to allow the screensaver on specific systems, which makes no sense.

*EDIT*

This is a 1min, 30sec video of the problem on my computer. This uses DOSBox 0.72, the one linked on the DOSBox homepage, not a custom version. Thought maybe it would help.

Bug