This decouples the regular timing from that dos call, which is plain wrong.

Also I doubt this compiles with msvc as-is.

Can anyone give me advice on how to get this included in DOSBOX upstream?

You can't. If a patch is useful it may or may not be accepted to be included.

"This decouples the regular timing from that dos call".
Why does "INT 21,2C - Get Time" have to attempt to be coupled with regular dos timing.
I was thinking that the Get/Set Time calls in the original MS-DOS would just read/write the RTC, and not adjust the interrupt timer ticks.
Which other function calls does the 2C - Get Time need to be coupled to?

Why does "INT 21,2C - Get Time" have to attempt to be coupled with regular dos timing.

Because otherwise a lot of things don't match, simplest example is that pause creates inconsistencies (large-scale example).

and not adjust the interrupt timer ticks.

Where do you see dos ints modifying the timer?

jcdutton wrote:

I have an old DOS app that needs accurate time

...DOSBox isn't designed for your non-game app.

So to answer your question:

jcdutton wrote:

Can anyone give me advice on how to get this included in DOSBOX upstream?

Prove that it's useful for DOS games, write a solution, submit it.

Or, create a fork of DOSBox to run your non-game app.

"Because otherwise a lot of things don't match, simplest example is that pause creates inconsistencies (large-scale example). "

Do you mean "pause" as in to pause the dosbox VM so that you can go off an do something and come back later and continue where you left off?
So, although this sort of "pause" feature was not in the original MS-DOS, I can see how it would be nice to have for games.
It is useful for me to understand what my suggested changes break, so thank you.
Even if I do keep a fork as some of you are suggesting, I would want my fork to break as little as possible.
So far, my patch breaks:
1) Pause (I don't think I can fix that, but I can document my fork with: This breaks the pause feature.)
2) Compiles on Linux, fails to compile on windows. (I can fix that fortunately)

Can anyone give me a pointer as to where in the dosbox code I could add a config file parameter so that I can switch this feature on/off without recompiling.
I could then use this config parameter to also disable the pause feature if my new time feature is enabled.

"Where do you see dos ints modifying the timer?"
I could be wrong here, as it was a long time ago that I looked at it.
As I understand it, there is a timer routine, and each time it is called, it increases the "tick" counter. I think on real hardware, this timer routine is triggered from the hardware timer interrupt.(maybe IRQ0).
There are certain situations where this interrupt is masked, causing the counter not to "tick", thus loosing ticks.
Now, on original MS-DOS, this loosing ticks was OK, because the get-time function did not rely on the ticks for its value, so original MS-DOS still kept quite good time using the RTC instead.
But, DOSBOX has this "pause" function, and I cannot see how to get this "pause" function to work as expected and still use the RTC.
If DOSBOX wishes to simulate MS-DOS on real old hardware more accurately, I don't think it can and still retain the "pause" function. Perhaps a config file parameter could be used here to decide whether to simulate RTC accurately or not.

There are certain situations where this interrupt is masked, causing the counter not to "tick", thus loosing ticks.

Yes, that's how it works. Same if you forgot to call the old int8 or failed to simulate its effects.

and I cannot see how to get this "pause" function to work as expected and still use the RTC.

That's why dosbox uses the emulated rtc and not the real system's rtc.

I don't think it can and still retain the "pause" function.

Works fine as-is. And nobody really cares if you lose a second per day.

hello jcdutton

Have you finally suceeded to build a DOSBox with a more accurate time? I would be very interested in that build, since I've the same problems as you (old dos software which needs accurate time). How accurate is you DOSBox environnement? I get differences of up to 4 seconds per hour.

I too would be interested in this.