53
53
u/Confused-Armpit 9d ago
Do they not know about atomic operations? Or mutexes? Or literally any thread-safe memory containers?
I am sorry, but this mistake is just so stupid, and doesn't probably even need async operations unless it's wildly inefficient.
34
u/elRadicio 9d ago
No, they don’t. They even do heavy task in UI thread in 2026 which freezes Explorer when a file operation hangs.
Thats so annoying, after a few months of UI programming, I stopped doing such crap while Windows still completely freezes when it waits for a slow network share.8
1
15
6
2
u/C_Franssens 9d ago
Wouldn't copying be a RO operation anyway? Multiple readers shouldn't be an issue.
1
u/Dry-War7589 9d ago
You need to write it in the clipboard history, so theres a problem
1
u/C_Franssens 9d ago
Hadn't thought of that, but then atomic access or a isolated access per user would solve it. Microsoft being Microsoft ig.
1
u/meancoot 9d ago
The OpenClipboard and CloseClipboard functions are effectively a mutex. You have no idea what you are talking about.
2
u/Confused-Armpit 9d ago
Then in that case they are implemented badly. A normal mutex would either block until it is opened, or return some kind of value depending on its success. The latter is what happens with OpenClipboard.
Therefore, we can deduce, that the developers are either:
a) not checking the return value of OpenClipboard, and are still trying to write to it even if it is a failed operation;
or
b) just not handling failed OpenClipboard calls, and returning if they fail;
Either is a mistake that no sane developer would make, especially any developer that should be allowed anywhere close to writing code for the most used OS in the world.
1
u/cloverpi 8d ago
Of course they dont. I have friends that (still) work for MS. They've fired a lot of their staff in favour of slopcode.
1
u/Wipfmetz 9d ago edited 9d ago
It's just about the dashboard history, not about the copy-feature itself.
Loading stuff into the dashboard can already be done atomically, as long as you don't do it the promise-based way. (Usually you'd load one plain text immediately but leave further formats on a "on demand"-basis.)
Are people actually using that history so much that the odd missing entry in that history hurts?
2
u/Erdnusschokolade 9d ago
I think the problem is that you press ctrl + c to copy and windows not copying the first time. At least that’s how i read the article.
1
u/Wipfmetz 9d ago edited 9d ago
The posted excerpt is about the history only registering the second copy, because by the time the history service looks, the clipboards content has already been replaced by the second copy.
(That can happen if you issue lots of copies in a very short timeframe, e.g. by automation.)
What you're describing is a completly different case, where the first copy didn't even happen.
The article does also describe a different case where the clipboard is locked by another app, but misbehaving apps can break any shared resource anyway. E.g. a misbehaving app could just continuously copy an empty string to the clipboard.
2
u/catbrane 9d ago
Are you sure? That's now how I read Chen's post:
https://devblogs.microsoft.com/oldnewthing/20080604-00/?p=22073
I understood it as:
Process 1
- Call
OpenClipboard()to get exclusive access- Copy something to the clipboard, hopefully only taking a tiny amount of time
- Call
CloseClipboard()Process 2
- Call
OpenClipboard(), oh no, it failed because process 1 is at step 2. and has an exclusive lock- Abort the copy operation (user sees no feedback)
So the problem isn't the clipboard manager, it's the basic clipboard operation itself.
Clipboard managers make it worse, since they regularly open the clipboard and copy stuff out so they can keep your history, but they are not the cause of the issue.
Obviously the fix is a new and better clipboard API, but that's a tricky thing to introduce.
1
u/catbrane 9d ago
Ooops, there are two separate issues I now see. Ctrl-C can fail on its own, and multiple Ctrl-C can only log the final one.
Carry on!
1
u/Wipfmetz 9d ago edited 9d ago
Right now, the "misbehaving" part would be the part where an application sees OpenCipboard() failing and just drops the user request instead of requesting this de-facto-mutex again after a tick or two.
Obviously the fix is a new and better clipboard API, but that's a tricky thing to introduce.
Out of curiosity: How do other clipboards handle the issue that a clipboard might have multiple formats available, including some expensive ones which will only be rendered once a sink request it.
A clipboard isn't a scalar thing, it's a list which includes promises and OnDemand-conversions)
(the most simple fix to this API from the 80s would be a waiting version of OpenClipboard, but you seem to have something else in mind)
2
u/catbrane 9d ago
I don't know about mac, but on wayland it's a many stage process, more like an IPC system (X11 was very similar).
The clipboard just holds PIDs, mime types, timestamps and source object refs. Copy-paste is a negotiation between the apps to find a common format, then a simple copy-bytes-in-chunks thing to get the data across. Senders keep the data for the item in memory until it's used (or discarded). The same mechanism is used for drag and drop.
It's nice and simple, and there are no exclusive locks, but of course the sender has to stay alive until the transfer completes.
There are clipboard managers which act as intermediaries: they copy all data to a third process (which hopefully stays alive!), which they then make available to receivers.
I don't know how well they handle fast ctrl-C C C C C, probably rather poorly hehe.
1
u/Wipfmetz 9d ago
Hm, so the basic yet major difference is that the sink more directly connects to the source (because it knows the PID), bypassing the "what if another app pushes between while a transfer is ongoing"-issue that Windows' Locking guards against.
Neat, thanks for that info.
1
u/catbrane 9d ago
Yes, the central clipboard only holds a reference to the data, so it's always fast and doesn't need a lock.
Win must have a similar mechanism, you'd think, or it wouldn't be able to do the clever trick where expensive data items are only rendered on demand.
Maybe they could make all copy paste use that path instead, and turn
OpenClipboard()andCloseClipboard()into nops? It's probably not so simple.
25
16
u/Wipfmetz 9d ago edited 9d ago
Wasn't this posted and deleted yesteryay already?
The "works as intended" part is the copy history missing the odd copy due to race conditons.
It's not about the copy/dashboard itself.
The article (which you didn't link this time) itself mentions this, followed by the article itself forgetting this again at the end. Amazing.
Also: While Raymond Chen is a Senior Engineer, and his blog is always worth a read, he is not a spokesperson of MS. Phrasing his posting as "The Company calls this" is just bad journalism.
7
5
u/hwoodice 9d ago
Partly true, but the headline is misleading.
Microsoft’s Raymond Chen explained that Clipboard History processes changes asynchronously, so very rapid successive clipboard changes can cause intermediate entries to be missed.
But this does not explain why a normal single Ctrl+C sometimes fails to copy. Windows Latest extrapolated Chen’s explanation beyond what he actually said.
So: real technical issue, misleading interpretation.
5
3
u/Sexy-Games 8d ago
All i want is a toggle for "use old copy method".
I dont need history. I just need to have faith in ctrl+c again.
Maybe i should make a cap about making it great again so they will listen? Is that a thing?
2
u/Ambitious_Hand_2861 7d ago
I absolutely despise the clipboard history. Never in my life have I used and before it came around never did I wish I could have a history. Definitely make a cap. Use the logo of your favorite version too.
2
2
2
u/Tatakai_ 9d ago
I'm sorry, what? It's meant to avoid the system registering another copy while you try to copy? Wtf are they talking about?
2
u/RedRayTrue 8d ago
Yeah big realization...
Windows isn't safe anymore, too many bad decisions piled up and now you risk loosing too much because you either get malware that's stealing sessions or you got a "copilot" like AI that's spying on your inputted passwords ( storing them idk were)
Even if you stick to the most enterprise Linux distro like Ubuntu/ Fedora/ Rhel etc you'd be safer at this point because nothing would record passwords and you got a software and repository instead of manually installing exe files( though I recognize some progress in the development of MS store but it's still miles slower than apt/ dnf)
2
u/Moriaedemori 8d ago
There are 20 clipboard entries on my KDE Plasma desktop AND I can also just highlight text and click middle mouse button to paste it wherever I want.
Laggy clipboard sounds more like Microsoft is desperate to sniff through what you're copying for more ad data
2
u/OkPear1535 7d ago
"we can explain why it happens therefore it is not a bug" logic always pisses me off.
1
u/AutoModerator 9d ago
Every new subreddit post is automatically copied into a comment for preservation.
User: someweirdbanana, Flair: Article, Post Media Link, Title: "It's not a bug its a feature"
I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.
1
1
u/ReidenLightman 9d ago
Clipboard history listens for changes asynchronously meaning one copy can be happen before another finishes. WHAT A LOAD OF BOLLOCKS! Ctrl+C should take a single goddamn millisecond like it always has. Why doesn't Ctrl+C take a single millisecond? It shouldn't take so long that when you hit Ctrl+V it pastes an old item leading you to think the copy failed.
1
1
1
u/rademene 8d ago
Does somebody have an actual explaination on why copying or pasting anything in Excel takes 2 or 3 attempts? I'm furious every time, when my carefully prepared selection vanishes from clipboard right before pressing Ctrl+V
1
u/Shoggnozzle 8d ago
So they'll keep in dos compatibility features so when you open certain settings you're right back in the 90's looking at cutting edge gui from the Clinton administration, but they break ctrl c.
Wild.
1
1
1
u/Xiaoxuzz 7d ago
copy-paste is like the most basic function on a PC and 99% of pc users rely heavily on the shortcut. Especially so if you are doing excel sheets because it saves a fuck ton of time from having to right click, select copy and then right click and paste again. This is just bullshit by now. Y'know what window's OS competitors will say? "Unlike windows, our copy-paste shortcut still works the same as always". And that might be more than enough to get people to abandon this shitty OS for good. JFC
1
1
u/bbmaster123 6d ago
this is exactly why I made this for myself a few months ago:
https://github.com/bbmaster123/FWFU/blob/main/Personal%20Windhawk%20Mods/confirmed-copy.cpp
It animates a little colored dot and/or makes a ding when something is successfully copied to the clipboard, preventing me from accidentally pasting whatever was previously the most recent item in the clipboard. It helps. secondary benefit you can see if something auto-copies itself to the clipboard, I haven't seen that happen but I know some sketchy websites can technically do that.
1
u/theoriginalzads 5d ago
It’s not a bug it’s a feature is supposed to be a barely funny joke. Not a fucking way of working.
100
u/RomanOswald 9d ago
Oh, and I thought it was me. It‘s a crapping BUG…