Well, it seems at least one of the recent commits (post r4006,) has broken the timestamp fix. Any chance someone is in a position to fix it again? There are several games that require it to install properly. Any game that uses a compression system that uses a files timestamp as part of the verification process will fail to install. I have to admit that I've never understood why the developers made the decision to force all files to have a modern date, even when the software (game, installer, whatever,) was trying to set them otherwise. From what I'm reading, the issues were with setting the timestamps to the "current" time. But the install problems occur because the installer tries to set the timestamp to the files "original" date & time. Either while unpacking from a compressed archive (in which the coded values are given,) or when copying a file with the copy command (where it copies the code from the original file.) In those cases, the values are set, there should be no need to calculate location or daylight savings.

All that being said, since we are simulating a DOS environment, wouldn't we really only need to worry about the original (simpler,) DOS timestamps, and not all the extra ones that modern Windows provides? In the official release version, that is. The expanded versions (where people want to add in Windows 95 support, and such,) would need to have expanded coverage, but that could be left to those adding in the extra support.

As it stands, I'll be rolling back to before the change that killed this particular patch. Not sure which exact revision it was right now, but it shouldn't be that hard to find. Until a timestamp fix is either committed, or an updated patch is written. I generally like to keep relatively modern under the assumption that patches & commits are made to expand compatibility, and I still have an extremely large library of old games I like to play occasionally.

FeedingDragon wrote:it seems at least one of the recent commits (post r4006,) has broken the timestamp fix.

It is almost certainly r4058 that causes difficulty in applying the existing patch, and you can either restructure the patch accordingly or revert r4058 in your personal build.

FeedingDragon wrote:I've never understood why the developers made the decision to force all files to have a modern date

I think you kind of have that backwards, as a current stamp is the natural behavior of the host OS when creating or modifying files, and it is the patch here that "forces" the stamp to be something else. In any case, my understanding is that the patch is not in official source primarily because it is not (yet) a cross-platform solution, and not because there is some ideological opposition to the feature. Also, as I have mentioned elsewhere, there is a positive aspect to the current behavior in that malicious software (viruses and the like) cannot hide modification of executable files by preserving the old stamp.

I wasn't intending to start the conversation on whether DOSBox should allow programs to change the timestamps again. I was just asking if anyone was working on adjusting "this" patch? So far it's proven to be beyond my limited programing ability My comments about games that require it were more on the line of why I would like someone to fix the patch, in the hopes that a better programmer will fix it. BTW - Thanks for the link, I can now list 2 examples (as requested,) of games that want to set the timestamp (Archon & Abandoned Places.) I installed the patch to get those working, so I have no idea if any of the other games I've tested need it or not.

As for naturally changing the timestamp on files, I was mainly commenting on the developers choice to update the timestamp on files that would, under normal circumstances, not have it updated. But, I'm not planning to go into that, this request was for something else (see paragraph 1.) As for why I prefer to have accurate timestamps over just setting the variable to override ARJ's check, there are a couple of them. First, nothing is stopping a game from having the same issue with a different archiver, or using one that is stripped down (so that the variable doesn't work.) Second, A hardcore game collector can use the date/time of an installed program to determine which version it is (the disk & even the program itself don't always give you this information.) Finally, it's just more aesthetically pleasing to have accurate timestamps when a directory is pulled up (to me, at least.) What good is it to sort a directory by date, when all the dates are the same?

In case anyone is curious, I only discovered this because one of my patches on my personal DOSBox build broke the installer of a game I was testing. I was going through my patches, one at a time, to see which one(s) it was when I discovered this problem Turns out it was the mouse copy/paste portion of the Long File Name patch (managed to yank that half of it, and keep the LFN support.)

FeedingDragon wrote:I was mainly commenting on the developers choice to update the timestamp on files that would, under normal circumstances, not have it updated.

This is the mistaken perception that I'm still trying to correct: it's not a decision or choice that was made; it's behavior of the host OS for new and modified files that has to be countered. Please understand that local folder mounts are not "normal circumstances" for what some DOS programs try to do with the DOS file system. BTW, there is a similar issue with file attributes that affects a small number of games.

Shall I then post an update to my patch suitable for the current revision, only to gulikoza's original patch that will get Daylight Saving Time wrong on Windows, or none at all? Given that my patch only has 3 downloads while gulikoza's has 381, I assume that people do not like the additional overhead that getting it right on Windows requires.

The download count on gulikoza's first patch is much higher because the thread was in the development section for around 5 years before it was moved to the patches section where downloading attachments is restricted to logged-in accounts. Given the difference in age and the section restriction, the difference in download count is not meaningful. Since you're probably going to update your more precise patch anyway, why not just go ahead and attach it?

Greatly appreciated In all honesty, I'm not worried about absolute accuracy on modern timestamps (in DOSBox.) I'm not even completely sure which patch I had been using up till now. I know I had tweaked it to also cover commands that (in DOS,) would preserve timestamps as well (Copy, Move, etc...) Though I don't remember exactly what I did to cover those. I'm an amateur programmer at best

I'm mainly here this time in the hopes of getting an up date from NewRisingSun Fixes are continuing to be committed, and some of them sound like I might want to incorporate them. I know you have other things (your own relaxation, maybe a job and/or other responsibilities,) so I'm not trying to rush you or anything. Just curious on how its going. Also, thank you again for offering to fix it I have a set of patches I apply to my personal build. I'm actually rather happy with my current build. Still need to get MP3's working with CUE sheets (different thread,) but I'll get back to working on that eventually. Will still have to track down where the issue lies, and probably get help fixing the issue. I'm really only good for applying other peoples patches & minor tweaks of my own.

That being said, I would like to comment on a previous post as well. Its sort of been sitting on my mind all this time. I don't really want to derail the topic, so I'm mainly just putting it out there to be thought about.

ripsaw8080 wrote:

FeedingDragon wrote:I was mainly commenting on the developers choice to update the timestamp on files that would, under normal circumstances, not have it updated.

This is the mistaken perception that I'm still trying to correct: it's not a decision or choice that was made; it's behavior of the host OS for new and modified files that has to be countered. Please understand that local folder mounts are not "normal circumstances" for what some DOS programs try to do with the DOS file system. BTW, there is a similar issue with file attributes that affects a small number of games.

This is one of the reasons I always refer to DOSBox as a simulator instead of an emulator. Sophistry, I know, but it is a little important to me. In the original (DOS,) environment, the program in question (archiver or installer in these instances,) does something during file creation that sets the time stamp to match the one stored in the archive or on the install disk. However, the host OS doesn't recognize these actions as such, and thus treats the file as any other new file. This is a departure from how the original environment worked. From my, admittedly limited, understanding, this is because DOSBox isn't replicating the complete functionality of the original environment on a HW level, but is actually acting as a SW layer between the simulation and the native OS. It's a choice made early in DOSBox development, and has made it's functionality a lot faster and, from what I understand, easier to implement on a cross-platform basis. The fix for this would be to recognize the actions that would cause a file to have a fixed time stamp instead of having a new one generated in the original environment, and then utilizing whatever system the host OS would use to accomplish the same thing.

Operating from 2 basic precepts: 1) The purpose of a simulation is to approach as closely as possible the original environment in the simplest manner available & 2) The stated goals of DOSBox is to experience vintage games as accurately as possible. From comments and such, I'm adding to that - without the heavy overhead of massive HW function replication (chip level re-creation in software.) In the original environment, action "x" would "normally" set the time stamp on the destination file to something other than the current date & time. However, the decision was made to disregard this aspect of the original environment. It's "this" decision that I don't understand. In an earlier thread it was stated that inaccurate results of up to 2 hours appeared in the time stamps of created files due to varied location (time zone & daylight savings time.) But if you are copying a time stamp from file A to file B, I'm confused as to how the location would have an effect. The only way I could see this having an effect is if you were generating a "calculated" timestamp instead of copying data that is already there.

The only aspect of difficulty I see is that commands to set a file stamp to other than current date & time may vary from compiler to compiler or OS to OS. But there are already sections of code that allow for this with other functions (#ifdef _WIN32_ for an example.) Yes, may not be accurate in fine, but in broad it is correct.

Again, I am an amateur programmer at best, so I'm fully willing to accept that I'm missing something. There may be something I just don't know. But because I'm missing it, or don't know it, I end up not understanding it as well. Sorry.

As a final note on another comment made here. There is really only 1 issue I keep bringing up on a regular basis (once a year or so at most.) The time stamp, I pretty much dropped for the most part. I only brought it up again, as I said, to ask if anyone was willing to fix the patch, that I'm "not" asking them to incorporate into the main code. The other stems from games that I just cannot play without breaking the rules. Both my own, and the ones given by the developers on this board. Some I've managed to find a perfectly legitimate work around for. OK, only 1 so far. But others are still sitting in my disk caddy unplayable That is another thread though, and doesn't have anything to do with time stamps.

Because I thought I might be able to use this in my project, I re-created the patch for current SVN. I have no idea whether it actually does what it's supposed to do, but it builds correctly under Visual Studio 2010. Thanks to FeedingDragon for doing all the real work!

You do not have the required permissions to view the files attached to this post.

The patch uses an operating system function to convert time. If your operating system treats Daylight Savings Time (or a future lack thereof) correctly, for example thanks to a Windows Update following such action by the European Union, then so will the patch.