What is the name of the game you are having the issue with?

It's not a game - yet. I've been trying to resurrect some old build tools which rely on Int 21h AX=5701 Set file date/time. A simple example is Borland's touch.com utility, which updates the date/time stamp of a file to the current time.

It doesn't look like a particularly onerous fix, just a few lines of code...

David00 wrote:

It doesn't look like a particularly onerous fix

Probably because you haven't considered all supported platforms. 😉

Patches (for Windows) have been made, and the feature discussed at length:
File Timestamp (DOSBOX Windows XP+)
Date & Time Mismatch?

Alternative is to boot DOSBox with an HD image.

Hello, 6 years on the source still shows this service as unimplemented. Just curious as to why?

I like to set the "time" of files I distribute to the version, for example if you look in a distribution .ZIP of my Micro-C compiler, you might see:

12003-06-02  3:23:00        22315 MCSETUP.COM
22003-06-02  3:23:00        13496 MCP.EXE
32003-06-02  3:23:00        26078 MCC.EXE
42003-06-02  3:23:00        13986 MCO.COM

Which lets you know that this is an archinve of version 3.23

As this is all DOS based stuff, I use DosBox to maintain much of it these days, and I can't do this within DosBox as my TOUCH command appears to work but doesn't because DosBox doesn't support INT 21h AX=5701h

I may fix this at some point (I've made other fixes to DosBox), but so far I've not... My "simpler" solution was to add an ability to my ZDIR command (List content of .ZIP in directory listing format) which lets you set the timestamp of files within a .ZIP:

1ZipDIRectory
2use:    ZDIR zipfile[.ZIP] [pattern][=[yr-mo-dy]-[hr:mi:se]]... [options]
3...
4If =yr-mo-dy-hr:mi:se  those values in pattern-file timestamps will be changed
5(TOUCHed)   * =skip but don't change.     If first seperator is ':', only time
6is changed (not date).   Some OSs (Windows) don't accept = (use "pattern=...")

Still annoying as it means modifying various programs, .BAT files etc. that I use to create these distributions (at least the ZDIR method still works in native DOS)

---
But what I consider a more serious problem is that when you COPY a file the timestamp on the COPY is the CURRENT time, NOT the timestamp of the original file. As I've written many tools over the years to maintain backups and auto-update files between various systems based on those file timestamps, this inability really confuses these tools. So, I have to perform such operations on the host OS (in my case Winblows) - which ment rewriting most of said tools for 32-bit OS, and just abandoning some operations because I really don't want to get that deep into it.

-- And I don't "buy" the arguement that "some host OSs might not support it".

What modern OS doesn't support some form of "touch" to a set timestamp?

and .. if you have an OS that doesn't, then DOS (remember this is DosBox) INT 21/5701 can be unsupported in that particular implementation of DosBox.

The whole idea that "DosBox won't support a fundamental function of DOS because it might not be supported in some of the host OSs" just seems "wrong" to me.
There are *many* DOS functions which have to be done differently from one host OS to another. That's the whole idea of "porting".

David00 wrote on 2026-03-28, 08:58:

Hello, 6 years on the source still shows this service as unimplemented. Just curious as to why?

Read the threads that were linked earlier.

If you really must have timestamps... use a HD image with real DOS, as was already suggested.

DosFreak wrote on 2019-12-09, 23:12:

Alternative is to boot DOSBox with an HD image.

I do this sometimes ... but it really disables one of the prime capabilities of DosBox over other virtual machine systems... The ability to directly access files on the host (via "mount"ed drives)

Modifying file timestamps in booted DOS works - but you have the problem of getting files to/from that booted DOS system, as the it doesn't see the host filesystem, and the host doesn't see its filesystem.

It *is* possible to setup a network between booted DOS and the host, but simple DOS network clients are old/insecure and getting them to work involves reducing the network security of you "modern" systems (assuming of course you know what needs to be changed and how). And getting networking working beteen DOS and non-MS OSs is not all that simple, and no guarantee that it will support full DOS filesystem compatibility...

What I usually do is ZIP files and transfer the .zip ... fortunately I have FDI.COM which lets be add/retrieve files from Floppy Disk Images (which can be made imgmounted to the booted DOS), For .zips >1.4m, I use DDLINK to transfer them to/from either over a packet network connection, or a nullmodem serial link.

In the end I just modified ZDIR to change timestamps in .zips directly.

(and yeah - I see that this thread is old.. I just don't think I saw it before)

In either case you have to extract the files from the .zip on the host... unzipping within DosBox will replace the timestamps with CURRENT time!

(yeah - I know this thread is old - I just don't think I've seem it before)

Thanks for all the feedback.

I have a few real DOS machines, so haven’t felt the need to load any HD images of DOS into DOSBox. But do use DOSBox from time to time, as it’s much easier to copy files from a more modern system to the DOS environment, as DaveDDS noted, and more convenient when travelling. Otherwise you are reliant on ZIP drives or dual-boot systems, both of which are tedious. Knowing that certain legacy build tools won’t work, I have work-arounds to address this when using DOSBox.

It was more of a philosophical question. I understand there are patches – but don’t those need incorporating into a release? My question was asking why, if there is this known issue in a basic Int 21h function, it hasn’t been fixed in a new release.

Isn’t compatibility a big concern? If it can be fixed for some supported platforms, then shouldn’t it be? Other platform versions might then behave differently, highlighting the need to find a fix for them. Is it that hard to date-time stamp a file on non-Windows platforms? Hypothetical questions...

Perhaps no one is maintaining DOSBox anymore. I don’t understand enough about the development process and community, hence my original well-intentioned enquiry.

David00 wrote on Yesterday, 19:05:

It was more of a philosophical question. I understand there are patches – but don’t those need incorporating into a release? My question was asking why, if there is this known issue in a basic Int 21h function, it hasn’t been fixed in a new release.

I 'll give a go at trying to answer you question.
Dosbox was mainly meant for running old games.
Since there is no, afaik, game that requires that function you ask about, that function was deemed unnecessary for running games.

Now to complicate matters further these days with all the supported platforms and each having it's own quirks & routines to set the date & time on each platform the likelyhood of it being implemented in dosbox, which is mostly meant to run games is highly unlikely.

anyway, my 2cents on it.
If I read it correctly that seems to be the gist of it.

@weedeewee, thanks for the explanation. It explains why the first response to my original post asked for the name of the game I was having issues with.

In the links from 6 years ago, others were reporting issues with games, especially installation-related. There was a patch available so I’d assumed there would be a new release of DOSBox.

It seems strange (to me) to persist a version of DOSBox with known non-compliances with MS-DOS, when there are existing patches. But perhaps I’m showing my age.

I’ve become aware of DOSBox-X which claims to be an accurate DOS emulation, and I’ll look at whether this provides a solution for me.

I do think this should be implemented in standard DosBox.

I've made as much workaround as I can (ability to TOUCH timetamps of files inside a .ZIP), ability to outsource COPYs to host, but...

Although the INT 21h call itself might not seem needed for games, it is a standard capability of DOS, and I do see how it can affect the ability to manage your games.

One big effect of not being able to set timestamp, is that COPY does not preserve timestamps, and any restoration operation (like UNZIPing) does not restore timestamps.

I can envision games using the timestamp to determing the latest save state file... and making a backup COPY of an older play would suddenly make that new copy (of an older play) the newest play! Likewise restoring an older play (say to give it to someone to check out) would suddenly make it the newest play.

Less likely, but I could see a game using timestamps to relate files which could also get confused.

I also don't buy the argument that "some platforms may not support this operation", in these cases you simply don't support this function on that platform. Thats much better than not supporting it at all.

---

If a patch does exist, why not incorporate it. I really never got the DosBox devs being so anal about not including ANYTHING games don't use... I've neved seen a games which used the DOS(Box) HELP command (and if one did, it would likely fail as DosBoxs HELP output is not the same as DOSs)... so why is it in there?

(Oh, it's convient? - but why does that count when other DOS convienences like preserving timestamps on COPY or restoration operations don't)

---

I haven't seen a patch - can anyone tell me exactly where it is? I use my own recompile of DosBox to include some patches that are not standard, and you love to include this one.