default configfile ?

Afaik, yes. I will compare later. Only thing different is that I raised the ram to 64 mb (will confirm later), disabled xms, ems and umb. imgmounted an hd and then booted it. Is it tied to booting an image?

Nope, should work anytime. But be sure you create a completely new config
file to start with, and keep an eye on the console window what config is used.

tested again, and made sure to make the conf file as default as possible. Same behaviour with just running WfW 3.11 directly from a mount and not from an hd image/boot.
differences in the conf to default:
memsize=31
ems=false

When I have loaded Wfw it will keep CPU activity at about 48% (my CPU is hyperthreaded, so that probably means the "one" CPU it runs on is maxed out 😀). When I put Dosbox out of the focus it will go much lower to between 10-20% CPU usage. Maybe that is ok, for priority=higher,normal
I just tried with priority=higher,higher and it seems that higher as out of focus priority is not accepted or honored, since it behaves like normal. I couldn't reproduce the "almost no activity" behaviour through, right now. I'll have to keep looking....

maybe the mode switching max/3 code kicks in.

just now it behaved different again,I had switched cycles to max and then mounted an hd image, booted a Dos 7.1 floppy, and ran 98lite which modifies Win98 SE installation files. When I switch away from Dosbox, activity goes down to 2% 🙁

I didn't quite understand the problem yet (there is some as it behaves
different than before).
A few notes: the priority setting doesn't have anything to do with the cpu
usage but with how the cpu is shared between processes. So you CAN have
dosbox running at 100% cpu usage (1 core) even with priority=lower if there
is not too much other activity.

Compared to 0.72 there has been a change to the non-focused mode as
Qbix noted, but this is unrelated to the priority setting. Namely for the auto
cycles (max as well i think) when dosbox is unfocused the currently chosen
value is used as basis for a fixed value.
This is done to avoid the cycles to go very low (priority is reduced, usually
the user activates another probably-resource-demanding app).

it's just that in 0.72 Dosbox would not lose activity like that. When I ran a setup program in 0.72 I could just switch away from Dosbox, do other stuff and it would be done soonish. Now when I switch away, Dosbox activity, be it CPU usage or whatever will drop that low that it takes forever for such an installation to finish. Of course this only affects big installation like Wfw or (for testing purposes) Windows 9x.

Fixing crashes takes way precedence over fast-running background installations.
Still i wouldn't expect a that large performance degradation, the current way
to do it is to take the last value that was used for the cycles (this is not the
user-visible "cycles" thing but CPU_CycleMax), divide it by 2 and set that fixed.

You might want to log the value of CPU_CycleMax in the main loop in dosbox.cpp
as well as in CPU_Enable_SkipAutoAdjust (cpu.cpp, note the CPU_CycleMax /= 2
there).

Fixing crashes takes way precedence over fast-running background installations.

I understand that, I just wanted to report that, since it behaves so different to 0.72

Still i wouldn't expect a that large performance degradation, the current way
to do it is to take the last value that was used for the cycles (this is not the
user-visible "cycles" thing but CPU_CycleMax), divide it by 2 and set that fixed.

I'll go this rout then, thanks

You might want to log the value of CPU_CycleMax in the main loop in dosbox.cpp
as well as in CPU_Enable_SkipAutoAdjust (cpu.cpp, note the CPU_CycleMax /= 2
there).

I don't know how to log all this, so... I'll stick to the fixed cycles then 😀

In CPU_Enable_SkipAutoAdjust() just add another LOG_MSG that contains
the CPU_MaxCycle (before and after the /=2 ) so you'll get feedback of
what cycle value was set when switching away from the window, and what
value it has been set to (if this magically is not half of what-it-was-before
something strange might be there 😉 ).