yes that is right.
dosbox doesn't allow the date of time being set.

Metal and Lace has a different issue with its installer, nothing to do with date/time.
There's a fix for that on my website (pferrie.host22.com).

Qbix wrote:

yes that is right.
dosbox doesn't allow the date of time being set.

Ok, I remember reading that thread now. But it still doesn't explain why the installer is reading the date/time wrong. It asks for disk 2, then right off the bat says that the piece of archon.pkg on disk 2 has a different time/date than the piece it unpacked from disk 1, and the time date are identical on both, I've triple checked at least. So, it skips the remainder of archon.pkg. The fix, manually unpack that file from the archive, and place it in the directory.

Egads... I just checked, DOSBox doesn't only stop anyone from changing the time/date stamps on a file, it forces them all to todays time & date. Just tested with a fresh install of a game. Every single file set to 02-20-2014 19:30 exactly. Even a file copied in DOSBox has it's time/date stamp changed, outside of DOSBox they maintain... So, any installer that compares the partial file on the HDD (instead of saving the info from the previous unpack,) will find a mismatch. There's got to be more than the 2 games that this is a problem for.

peterferrie wrote:

Metal and Lace has a different issue with its installer, nothing to do with date/time.
There's a fix for that on my website (pferrie.host22.com).

That patch will come in handy if I ever find the disks again. I thought they were bad, and tossed them somewhere. Haven't been able to find them yet 🙁

This reminds me of a similar issue I had here : Eye of the Beholder III Install Issue

DOSBox doesn't only stop anyone from changing the time/date stamps on a file, it forces them all to todays time & date.

Well, it's the host OS that is setting the file's modification stamp to the current date/time, not DOSBox. DOS unarchiving programs call a DOS function to set the stamps of extracted files to what is stored in the archive, but DOSBox does not implement that function. Same thing for the COPY command, DOSBox doesn't set the destination file stamp to the source file stamp.

The DOS function for setting date/time stamps on files is not implemented because no cross-platform method for doing it has been found. There is actually some benefit: programs running in DOSBox can't cover up the fact that a file has been modified, and that applies to virus-infected programs as well. However, some unofficial builds, such as the Daum SVN build, implement the function on specific platforms.

There are only a few game installers that concern themselves with the file stamps. Some of those are based on ARJ, which has the stamp-checking behavior by default. Using the command "set arj_sw=-c" before running such installers is often an effective workaround, because the unarchiving program will then skip the stamp check.

Great Hierophant wrote:

This reminds me of a similar issue I had here : Eye of the Beholder III Install Issue

That's it exactly..... That switch is handy to know. Putting it in my list of common fixes file 😀 Also setting it up to be present by default in all my future DOSBox config files. I'm wondering why that thread didn't come up in my search 😒 Would have made things a lot easier. As for the cross-platform bit... Other platforms don't time/date stamp the files? Every one I've worked with (except the C64/128,) does. The Atari AT, Amiga, MACs, even my old TI put a time stamp on "disk" files (not on cassette files, though.) It seems to me it would just mean working through different libraries depending on which system you were on... Just like just about every other computer function. I'm just curious here, not a complaint. As long as I can work around it, it doesn't bother me any.

Most file I/O functions are not different on every platform... stat(), open(), read(), write() etc.
There is no standard equivalent function to set the timestamp of a file to a specific value, most platforms don't even have their own function for it.

but thats kind weird though,
in *nix realm we have "touch" program,
on dos realm, i remember Norton Utilitiess have a program called "FD.exe" or "File Date", which thanks to compatibility, also works on 32-bit windows regardless the underlying FileSystem (FAT/NTFS).
there also "touch" for windows that would works on 32/64-bit of windows.

all those program modify the files's "last modified date/time".

Windows is not fully posix compliant; and even where a time function is available, there is no guarantee that the value returned is in the same format among systems.

In any case, it has already been suggested to try Ykhwong's build with the time/date patch which may work (for specific systems).

Joey_sw wrote:

but thats kind weird though, in *nix realm we have "touch" program, on dos realm, i remember Norton Utilitiess have a program ca […]
Show full quote

but thats kind weird though,
in *nix realm we have "touch" program,
on dos realm, i remember Norton Utilitiess have a program called "FD.exe" or "File Date", which thanks to compatibility, also works on 32-bit windows regardless the underlying FileSystem (FAT/NTFS).
there also "touch" for windows that would works on 32/64-bit of windows.

all those program modify the files's "last modified date/time".

The fact that different platforms each need their own specialized programs (or an additional compatibility layer like ntvdm or cygwin) proves the point that I (and others) already made about there not being a standard, portable function to accomplish it - these programs are non-portable, written to work only under a specific OS.

Most compilers, such as Borland C++ for Win32, HiSoft C++ for Amiga, "whatever c++" for MAC OS X, etc... come with a set of libraries or "includes" that standardize this. Every system, for example, has a different means of drawing a box on the screen. The libraries take the details of how to do something (whether its drawing a box, making a sound, or accessing something in or on a file,) and then translates that into standard commands. So, to draw that box, the command might be: box(x-loc, y-loc, height, width) which would draw the box you want. The exact method of actually putting that box on the screen will differ greatly if done in OS X instead of Windows XP.

Thus, it was my understanding, that in the file access libraries, there "should" be routines for setting the date and time of the file. These routines would use standard commands (same from platform to platform,) that would do wildly different things depending on the platform they were compiled on. The only times I know of where this wouldn't be the case is when a platform just doesn't "have" any way to do what you want. For example, IIRC, the Amiga only has "one" time/date associated with every file, the creation date (or the last time the file was overwritten, the Amiga considers an overwritten file to be a "new" file.) So, the C library on the Amiga would only have only one "form" of date/time read/write in it's libraries. Meanwhile, Windows has 3 such entries. The creation date of the file, the date of the last "change" to the file, and the date of the last "access" to the file. A fully cross platform program would be written to only access the first one (creation,) or would have complex compiler commands to automatically skip or change any types of access that doesn't exist on the host system when compiled. Now, I'm not a programmer, though I started to study to be one back in college. So, I have no idea of the details of this. I took 1/4 of a semester of C programming, that was enough to tell me I don't have the patience to be a programmer.

What I was semi-asking was.... Isn't there a file library in standard C++ (the language DOSBox code "appears" to be written in,) that has file date/time commands? It may only change one, but it would be the one that, from what I understand, DOS used. Old DOS used to be like the Amiga I believe, with only one date/time associated with a file. The date of last change (write to the file.) So this would be the only date/time DOSBox would be interested in anyway. Again, I know about libraries, and I know there are a LOT of them. I just don't know what they all are. I only know a couple of them, and with those I only have vague memories at best.

FeedingDragon wrote:

What I was semi-asking was.... Isn't there a file library in standard C++ (the language DOSBox code "appears" to be written in,) that has file date/time commands?

There is not, that is precisely the problem.

Just did a quick search. There is a library, but all it does is allow you to access the host systems high level functions (WinAPI for windows.) You actually have to specify the function, so the command would differ from host system to host system. So the code would have to be different for every system. The block of code would have to include engine commands for the compiler to include/exclude blocks of code depending on the host OS and for every OS the code is written for. It seems to me, that the best solution for the authors would be to include a function for setting the time, put notes specifying instructions for the standardized engine commands needed (to keep the wrong code from being compiled when compilation occurs.) Then to have it do nothing. This would have the code doing what it does now, and basically stop programs from changing the time, but would allow someone else to include code to allow a program to do so. Then let interested third parties submit code to allow it on their preferred system. So, someone could write the code to make the appropriate OS X calls to do it some time in the future. And someone else could do the same for Windows, Unix, Amiga, etc.... This is especially needed for non DOS based systems (MAC, Amiga, etc...) where the end user cannot install the program natively then move it to their DOSBox directory to actually play the game.

Or they could just use "set arj_sw=-c" like has already been suggested.

jmarsh wrote:

Or they could just use "set arj_sw=-c" like has already been suggested.

That works with arj based installers that use DEARJ.exe to install the game. However, I can think of other ways the forced time stamp might cause a problem. Also, what if there are installers that I don't have right not (or haven't gotten to yet,) that have the same problem with a different packing program (that wouldn't be effected by this environment variable.) I'm not asking the developers to write the code, I'm asking 3rd party people who might be interested to write the code. I'm asking the developers, (if they haven't already done so, not a good enough programmer to check,) to put a stub in place to allow 3rd party development of this code. This issue is no longer a problem for me right now, but I have so many more disks to go through. I have a rather large box of original disks (some manuals even,) that I'm slowly working my way through. Some are good, some are bad, some I don't want, some I REALLY want but cannot use right now (don't have code wheel or manual for copy protection.) Many are for Windows 3.1, many seem to be for DOS. Looking at the box, there could easily be 1000 disks here. I may very well come across another time/date based problem.

There are already third-party forks that have implemented it for some platforms.

So far the one problem installer can be fixed by this if you come across another one it would be great to learn about it.
Implementing this and that because it might be needed could add unneeded bloat to Dosbox.
There are countless isolated special cases that might not be fixable through dosbox itself but by little patch programs. Just ask Ripsaw 😉
But please, if you can find the time, document your problems and fixes in the compatibility database...

File Timestamp (DOSBOX Windows XP+)

The next question then is, would this code prevent DOSBox from being compiled on another host system? Followed, if it wouldn't, by, is there any chance of it making it into the official code? Examining the differential file, I quickly got lost 🙁 But I did notice that it seemed to alter several different areas in several files. I also didn't notice anything in there that would prevent the code from interfering with compiling on a different host system. That it exists is great, but that does me little good, as I cannot add it to the code myself (unless there is some way to do it automatically that I don't know,) and unless it is all automated somehow, I cannot even compile the SVN myself anyway. I have Visual Studio 2008 (I think, would have to dig out the CD,) but other than installing it, plopping in the SVN, and hitting make (I think,) I don't know how to use it. If you're wondering why I even have it, it came in a group purchase on eBay. I have tons of stuff I cannot or do not use that came with other things I wanted in an eBay sale 🙁

Installing VS now, will download the latest source code and give it a try, but I'm afraid my compile will quickly become snarled, or I'll get lost trying to integrate the .diff file. I've started my search for integrating the .diff file and found references to the "patch" program, but haven't found the program itself yet. Also the patch was made in 2009, so the program probably wouldn't work anyway, and I'll have to manually integrate it, as the source code has probably changed quite a bit since then (making the locations the diff file refers too obsolete.) I usually just download builds from the wiki site. Even though it has functions removed, they are things I don't use anyway. I generally like to use only the official builds, only using others (like Daum,) when I absolutely have too, such as playing Tomb Raider with hardware acceleration. I think Tomb Raider is the only game I use the Daum build for right now.