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.
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.