FEAT: high res timestamps on W8+ #5295
Conversation
|
Very nice @hiiamboris. So we now have |
|
About 100ns really (precision limit of this API call). But On Linux resolution is 1us, |
|
Dynamic loading may have been a carryover from when @qtxie suggested it for Win7 compatibility. |
|
I would have preferred the use of static linking for such import and conditional preprocessing directive to compile the appropriate code depending on the platform. We could have created a new Also this kind of dynamic linking of kernel libs might increase the false flagging on AVs... |
|
Since Win7 isn't supported anymore, do we even need that legacy support? Time marches on. |
|
I'm all for dropping entirely Win7 and even Win8 support too. Windows 12 release is next month... From ghacks:
|
But we do not (and should not IMO) offer prebuilt consoles for different Windows versions. Anyway, as I know a lot of people are still using WinXP, and I myself would want continue using W7 on another PC, and I would find it strange for Red to not run on an OS capable of running any modern 3D game, so I prefer this solution. 2-3 lines of code is not even a price for compatibility. |
|
BTW another reason I did not use the #if directive for W8+ is because I don't fully trust MS when they say it's supported on W8. Maybe on some old build of W8 it's not supported? |
|
It's not just the 2-3 lines of code, but having systems we can test on, and dealing with the legacy systems and people that will have problems. I still have Win7 on more than one machine, and a couple old VMs going back to W2K (and DOSBox :^). Always tough choices, and I hold on to old stuff more than many, but we also have to shed baggage if we want to keep moving. The question is what value something adds, versus what it costs to support it. |
|
This would all be easier if new systems and OSs were unequivocally better than their predecessors. :^\ |
|
Also how we make things fail gracefully, so at least something runs, even if not full featured. |
|
As far as prebuilt consoles, I agree that we should not keep building old ones. What we can, and should do is make old ones available in a History Archive. |
Indeed. Unfortunately I expect they will be significantly worse in the next decade or two as they were degrading in the last decade but faster, up to total absurdity :) |
It's not about code size but introducing an exception in the way we handle OS imports for no good reason. Having a specific compilation target for Win7 is perfectly fine, I don't see any reason why not to comply with our existing design choices. Using dynamic loading suddenly "just because you prefer it" is just making the code architecture messier as we introduce an exception. There is no "compatibility" issue as Win7 users could compile for their own target as WinXP users do so far. We can add some info about that in the README page. |
I have to strongly disagree. What you're proposing will not only force Win7 users to build their own console, but also will make all compiled Red Windows executables Win7-incompatible. You are proposing that everyone who ever releases an exe have to provide different binaries for WXP, W7 and W8+. Have you ever seen anyone doing that? I haven't, because it would be quite a mess. The worst I've seen is separate 32- and 64-bit binaries, but that's because there's no way around it. And all that over what? More digits in the timestamp? :) You cite statcounter, but behind every number there's someone's huge money. Based on my own observations I would not easily bet what's more popular in my country - W10 or WXP . And it's not one of the overexploited countries (yet). It's understandable that commercial OS vendors would do all they can to push their users into faster and faster cycle of OS upgrades, to lock and spy on their users as much as they can. They just can't do otherwise. But it's always more pain for the users in the end. As developers the least we can do is be a bit more conscious and not help proliferate this madness ourselves. I understand it when maintaining compatibility requires enormous effort, but at least we should not make the effort to break compatibility when we have it almost for free. The ultimate programmers dream should be a single binary that runs on every platform, not a separate binary per every version of every platform. We have currently another 6 dynamic imports in runtime. One more doesn't make a difference. I have no reason to believe dynamic imports affect AV results in any way. I see no proof of it. VirusTotal shows 7 alerts for the View-less console without any dynamic imports, vs only 4 alerts for the View console that has 7 dynamic imports. Besides, we have to plan for Red-level runtime library loading, which will unavoidably use the same mechanism. If after reading my arguments you still can't accept this PR, I would prefer we just close it, rather than add a W8+ required import. |
Example output of
probe new-line/all loop 100 [append [] pick now/precise 'second] on: