VOGONS

Common searches


Reply 20 of 40, by FeedingDragon

User metadata
Rank Oldbie
Rank
Oldbie

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.

Feeding Dragon

Reply 21 of 40, by ripsaw8080

User metadata
Rank DOSBox Author
Rank
DOSBox Author
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.

Reply 22 of 40, by DosFreak

User metadata
Rank l33t++
Rank
l33t++

Another option is to see if the games install properly on a img booted in DOSBox.

A list of games with the issue would also be helpful for testing purposes.

How To Ask Questions The Smart Way
Make your games work offline

Reply 23 of 40, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

Yes, several games always sounds to me like Game of Obscuria Part 1 and two...
(But seriously I remember one or two games but not their name)

Windows 3.1x guide for DOSBox
60 seconds guide to DOSBox
DOSBox SVN snapshot for macOS (10.4-11.x ppc/intel 32/64bit) notarized for gatekeeper

Reply 24 of 40, by ripsaw8080

User metadata
Rank DOSBox Author
Rank
DOSBox Author

Ah, I remember now, FeedingDragon tends to write the same things (and receive the same responses) regarding the issue: Date & Time Mismatch?

Note that the linked thread describes a simple workaround for DEARJ-based installers, which represents most of the known problem cases.

Reply 25 of 40, by FeedingDragon

User metadata
Rank Oldbie
Rank
Oldbie

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

Feeding Dragon

Reply 26 of 40, by ripsaw8080

User metadata
Rank DOSBox Author
Rank
DOSBox Author
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.

Reply 27 of 40, by NewRisingSun

User metadata
Rank Oldbie
Rank
Oldbie

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.

Reply 28 of 40, by ripsaw8080

User metadata
Rank DOSBox Author
Rank
DOSBox Author

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?

Reply 30 of 40, by FeedingDragon

User metadata
Rank Oldbie
Rank
Oldbie

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 🙁

Feeding Dragon

Reply 31 of 40, by FeedingDragon

User metadata
Rank Oldbie
Rank
Oldbie

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.

Feeding Dragon

Reply 33 of 40, by FeedingDragon

User metadata
Rank Oldbie
Rank
Oldbie
NewRisingSun wrote:

I rescind the offer to fix it. Also, you talk too much.

I'm sorry I upset you 🙁 I'll go back to "trying" to figure it out myself, though I don't hold much hope for that. Thank you for whatever work you already put into it.

Feeding Dragon

Reply 34 of 40, by emendelson

User metadata
Rank Oldbie
Rank
Oldbie

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!

Attachments

Reply 37 of 40, by NewRisingSun

User metadata
Rank Oldbie
Rank
Oldbie

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.

Reply 39 of 40, by ari

User metadata
Rank Newbie
Rank
Newbie

I took the freedom to adopt this to trunk.

The original patch(es) have some problems, so I needed to rework it a bit. Main problem was that they work on file names stored in DosLocalFile Class. These however are mangled DOS style 8.3 names, not the orignal filesystem names.
(for example DOSBOX~3 instead of DOBOX-SVN-SRC). Trying to open these to set the time of course fails.
Also the modifications to implement this were both invasive and not conformant to the coding style used elsewhere in the files. The file system directory path of the file needs to be stored in the class and the original implementation does that without copying it, leaving a reference to the original string.
What however works well and is both less invasive and memory intense is to set the file time using the still open OS file handle. Unfortunately Linux does not provide futime(), but luckily there is an alternative available on all modern operating systems: futimens(). This should work with linux >= 2.6.22, NetBSD, FreeBSD , and MacOS. For Windows I use the SetFileTime() on the handle as in the original windows patches.
Care is taken to flush out any high level buffered file data, before the time is set. Otherwise the FileTime would be set to the current time when the file is close.
So this patch should work on any modern operating system - The only thing open is OS/2 - which I doubt is used for other then academic research any more.
I not sure and I cannot test, but even OS/2 should have something like _dos_setftime() at least for realmode applications. Borland C++ reference manuals list this as implemented for OS/2. Someone still working on this can try to implement it, it should be simple.

I tested the attached patch on both linux (x64) and Windows (X64, cross-compiled using a very recent mingw on SuSE) - both work correctly.
This now allows DOS games patching without complaining.

Enjoy

Attachments

Last edited by ari on 2020-12-23, 19:10. Edited 2 times in total.