Windows is the strangest, or hardest, operating system to keep curl support for
mastodon.social
mastodon.social
Is that the same wanker that got in a hissy fit over distros including xscreensaver ?
Edit: I liked vms fine, I don't think this is inheritance from that, or even dos. I knew how to debug in dos, using debug.com even. I think it has something to do with the lack of expectations for a user to be able to debug a problem. Osx has abit of this, but sitting on a bsd saves it to some extent.
To wit, Windows has plenty of debugging functionality. Historically not as extensive as Unix, but it was there.
However, 0% of that was exposed in any sane way, because Microsoft...? Actually, I have no idea why it wasn't. For the price of 2 senior engineers and a willingness to actually release tools, Microsoft could have drastically improved the situation.
Instead they just (eventually) bought sysinternals. :(
But the gui is kind of heavy and not at all like opening a text file in less.
If you're learning, start with the official windows docs. They are often very good.
Practically, though, it's a shit show. My "favorite" is the inability to delete a file that is open by another process. Combine this with Windows Defender that scans every file that your application creates, and now you have no reliable way of deleting or moving your files.
As someone who works on a C/C++ build toolchain and has to deal with Windows design decisions every day, I can tell you without any hesitation there is nothing coherent or beautiful about it. I don't think even Microsoft believes this.
What does the alternative look like?
Lets say a process has a file open. Lets say it is a really big one, like 200GB. Ok, so our disk is nearly out of space, better delete this 200GB file, problem solved right?
Only not. Because now even though the file looks deleted, the process still has it open and that space is still allocated to it.
So either you're hiding reality from the user, or you're preventing them from deleting a file that is in use. Windows went one way and UNIX went another.
When you open a file on Windows, you can share: read, write and/or “mark to delete”. A lot of times you don’t share any (read can lead to data incoherency; write means you can go out of sync in offsets with someone else; delete might not be relevant if it’s your database file). But if you do, the file isn’t “locked” if someone else opens it for the permissions you’ve agreed to share.
“FILE_SHARE_DELETE” is a little tricky because you can’t delete a file in use, because after all it’s _in use_. So instead, your request to delete puts a mark on it that prevents future opens, and completes the delete once the previously open handles all close.
And except for very specific cases (PE mapping, special “on-purpose” locking, specific APIs) you can always rename/move a file in use, so combined with “FILE_SHARE_DELETE” it’s sort of equivalent except for the space not being freed immediately.
There's two problems here, the process and the file, it seems you need to deal with both situations on both styles of OS. You could truncate the file (there's also a `truncate` command I have never used):
cat /dev/null > somefile
and let the process continue writing, or you could just `rm` the file, then either kill the process (or the other way round), or if you've got mysterious disk space usage issues you think are due to still open but deleted files you can:
lsof | grep deleted
I'm an ex (mostly) sysadmin and so this stuff is easy, but is obviously out of reach for "normal" users. Personally as someone who still uses Unix-like machines (Mac, servers) and Windows (games, chkdsk) and I greatly prefer the Linux/Unix way and find the Windows way frustrating.
Not naively intuitive, but for this you can write an empty file to the large open file with shell redirection.
cat /dev/null > /path/to/big/file
I get how this corner case sucks, but to me it seems so much better than the endless parade of reboots and application restarts necessitated by file locking in the Windows world.
Because of this Linux "feature" I experienced data loss - I zipped a file and deleted it, but the process which created it was still writing to it. But all the data that it wrote now ended up in the void since the file didn't exist anymore. And there was no error/warning that the process was writing to a non-linked file, so I discovered the data loss much later.
I can update glibc or other core system libraries on Linux without rebooting. Processes using the old library will show "(deleted)" in their /proc/self/maps files, but they will continue to use the old code. New processes will use the new library, and downtime was not required.
This is not possible on Windows because of mandatory locking on core system libraries. As a consequence, Windows must reboot for every Patch Tuesday.
There are only a few places that Linux has mandatory locking, and this is a good thing.
Here is a script that will show you all the deleted libraries that are still in use on Linux:
# cat stale_libraries.sh
#!/bin/sh
awk '$NF=="(deleted)" && $(NF-1) ~ /[.]so/ {
sub(/;.*$/,"",$(NF-1))
print $(NF-1), $NF}' /proc/*/maps | sort -u
# cat stale_programs.sh
#!/bin/sh
grep '[.]so.*deleted)' /proc/*/maps |
sed 's/[:][^/]*//' |
sort -u |
while read -r line
do pid=${line#/} pid=${pid#*/} pid=${pid%%/*}
xargs -0 printf '%s ' < "/proc/$pid/cmdline" | sed 's/[ ]$//'
printf :%s\\n "$line"
done
Linux doesn't need reboots only in theory. I have an Ubuntu server box and not a week passes in which I don't see a "system reboot is required" prompt when I SSH into it.
Windows does not allow this, which is why we have Patch Tuesday outages.
Also, Oracle KSplice was the first free tool to apply updates to a running Linux kernel without rebooting.
KSplice is free on Ubuntu. I think other free services have become available since.
There are mechanisms for updating the kernel in-place, and I believe canonical is one of the leaders in that domain, but if you're choosing not to use it and you don't want to reboot once/week, you can still keep your system level libraries up to date without rebooting.
The above poster didn't say you could update absolutely everything in linux without a reboot, just that the locking mechanisms in windows means you have to reboot to update things that don't require a reboot in linux.
My point was that in theory Linux doesn't need reboots and Windows does, but in practice my Ubuntu box needs a weekly reboot, while my Windows box just once a month.
What's true is that you can update everything BUT the kernel without a reboot.
Any understanding of theory that involved a belief that Linux never needed a reboot to update the kernel is a flaw in your understanding rather than a problem with the theory.
And in fact, the reason people have been working on being able to update the kernel without a reboot is finally put to rest that final mile. Personally I don't think it will ever come to full fruition, but the list of things that does require a reboot will become smaller and smaller over time.
https://cloud7.news/article/how-to-update-linux-kernel-witho...
> Rebootless Kernel updates are not a replacement for full kernel upgrades but it allows you to patch critical security vulnerabilities and bug fixes. With these methods, you can keep your servers safe and running without outage for years.
> Several Linux vendors offer rebootless kernel updates. Your solution mostly depends on the distribution you are running.
And finally, a bit more info about canonical's solution
https://cloud7.news/article/how-to-update-linux-kernel-witho...
Yet people keep saying that on HN, that unlike Windows, you don't need to reboot Linux after updating, and then maybe mention how they have months of uptime.
By default Ubuntu, the most popular distro, updates the kernel too. And frequently the kernel update is a security update.
It's possible your cloud provider has chosen to have its own package repository where they insist on doing this, but this is a decision by your cloud provider and not Canonical.
Linux has what's called Kernel Modules that can be unloaded and loaded at runtime without the need to update the kernel itself. I myself run ubuntu in vmware, and have done so for probably over 10 years, and your description of Ubuntu's default behavior is inaccurate.
---
But more than that, it's been explained to you, stop arguing.
The amount of harm "security" people have wrought to everyone else around them is astronomical.
I don't doubt your cloud provider made that decision, it's yet another example of security people forcing major inconveniences on everyone else in the name of protecting them. It might even be warranted here (it probably is), but I would almost put money on 85-90% of terrible situations in software dev having a root in a security person somewhere. That sounds outlandish, yet it completely matches my experience.
Linux assumes that long running processes just randomly exploding because they are living in a pre-hotfix ghost state is fine (and usually free of security concerns). Windows assumes users notice and get frustrated when long running apps start acting "weird" and don't know why and that there are too many security implications if you just leave unpatched apps running alongside patched ones.
It's another one of those things on the list that the NT Kernel has the raw design to do a lot of smart, deliberate things, but at the end of the day can't trust user space to play nice with them happening and is maybe a little too safety conscious of that.
(My understanding too is that Ubuntu is an interesting example here because Canonical now explicitly uses a more Microsoft-influenced security model in user-focused distributions for when to require reboots. Under the same general concerns: avoid user-noticeable "weirdness" and avoid unpatched CVEs remaining long running in user space. While it could just kill unpatched processes, that creates "user noticeable weirdness", and for better and worse a full "restart" is much less shocking to the average user than long running processes getting killed "weirdly".)
So, you experienced data loss because you deleted a file you didn't mean to.
...and?
In the example I gave, the other process was continuously writing to this file while I was zipping it.
If the process creating the zip file runs faster, and finishes, and closes the file, your attempt to delete it would have worked anyway. Because the program that created it didn't have it open any more.
The zip creation and me deleting the file were in parallel with another process writing to the file.
And I didn't delete the zip file, I deleted the original file that I zipped.
This is why you should always check the contents of your archive before deleting the originals. There are myriad reasons why the archive may be incomplete or incorrect. You were hit by one of them that happens to not happen on Windows.
OK, I think that's where a lot of the confusion comes from.
When you originally said "I zipped a file and deleted it, but the process which created it was still writing to it.", I thought the "it"s referred to the zip file, not the original file, and "the process that created it" was the zip process.
Going by your actual meaning - are you saying you zipped a file on disk that was still being written to? That's... weird.
Given that reading from disk is faster than writing to it, and the written data may well have been in the disk cache anyway, it's likely that the zip program could have "caught up" with the program that was writing the data, tried another read and been told "this is the end of the file", and then finished creating the zip file. That would have created an incomplete zip.
But also, as others have pointed out, just because you delete a file and it gets removed from the directory, the actual file and its contents stay around until all open handles to it are gone. So if one process has the file open and is writing to it, and a second process has the file open and is reading from it, if you delete the file then both processes should still be able to access it through their existing file handles, even though it doesn't have a directory entry any more. So you shouldn't have experienced any data loss from that series of events.
(And that's why having the "it"s refer to the zip file is a logical interpretation of what you said, and why a few repliers - including me! - seem confused)
That's how Linux works. Some programs, like rsync, will give you a warning at the end, similar to "the file was modified during the rsync operation". Most others, like zip will give no warning at all.
Someone with more knowledge please correct me if I got the above wrong.
That being said, the issue with Windows is that it prevents me from deleting a file if it's open in a text editor or any program, which should not be the default in my opinion. A directory gets locked simply because you have explorer open in that path, or a terminal cd'd into that path, which is annoying and counter productive most of the time.
The standard Linux compression programs, zip, gzip, tar, don't lock by default. I don't even think they have such an option.
File locking on Linux is advisory, it excludes other processes which try to lock the same region of the same file, but not operations other than locking. Mandatory locks were optional (required a mount option, see https://lwn.net/Articles/667210/ for details), and were removed in 5.15 (https://lwn.net/Articles/874493/).
Of course that's assuming the compression program used does attempt to apply file lock, which may not be the case according to another comment.
More precisely, what data was lost, and how did it get lost?
Process P, the data producer, writes to file foo.
Process Z, the zip-process, reads file foo and produces foo.zip
Process rm, removes file foo.
I imagine it went a bit like this:
P --output foo &
Z < foo > foo.zip
rm foo
# time passes
# process P terminates
User 323 assumed that either rm would fail, letting them know that foo cannot be deleted, or that P would throw an error when the file was deleted.
(I don't think this is a reasonable expectation, and it's a failure on 323's hand of not learning the UNIX file model, but there's the situation).
I think I can see the loss:
1. Start zip. 2. In parallel, copy the intermediate zip file. 3. Delete the zip 4. Delete originals
The data was deleted in step 4 and is the loss. It notably would also had occurred had the zip terminated early or not zipped _all_ the files for some reason. The process was not resilient.
I think it's debatable if it's reasonable to continue allowing writing to an unlinked file.
There was discussion some time ago about Postgres data loss because of something similar, where the linux kernel returned successfully from fsync despite the movable media not being present anymore.
> How is it possible that PostgreSQL used fsync incorrectly for 20 years, and what we'll do about it
https://archive.fosdem.org/2019/schedule/event/postgresql_fs...
In this case, you can have your cake (delete the directory entry) and eat it too (get the data back through /proc).
When the last directory entry for a file is passed to the unlink() system call, the file is removed from the directory hierarchy.
However, the data on media will be deleted only after all open file descriptors are closed.
One exploitation of this feature that I have seen is the SQLite temporary tablespace, which is created and immediately unlinked, ensuring that it will not persist after the program terminates.
Yes, it does. Windows is POSIX/FIPS-151
In any case, I have never seen any way to coerce POSIX unlink() behavior on Windows.
'Broad software compatibility was initially achieved with support for several API "personalities", including Windows API, POSIX, and OS/2 APIs – the latter two were phased out starting with Windows XP.'
And Microsoft's been trying to manage that insanity since 1995.
If yes - that sounds insane!
If no - it doesn't really help, then, does it? The complaint was that an application developer cannot create a file and then just move/remove it when they please.
I'm neither a Windows user nor Windows dev, so I might be missing something.
If his application can only work by creating and deleting files as soon as they are created, then it makes sense for him to point his users to the appropriate documentation.
I usually put it as "Deep inside windows is a really beautiful OS just screaming to be let out from under all that junk on top."
The NT kernel isn't that bad, different from unix for sure but still good. It then just keeps getting progressively worse as you go upwards in the stack from there.
And I understand people will argue for it because it does have some utility, but not near enough to pay for the all the damage it's done to people's time.
If you really want to close it and know you could break another process but don't care(Which you should), you can use NtQueryFileInformation to get the process ID's that have the file opened, then use OpenProcess with the PID, then use NtQueryProcessInformation to get the open handles. Call DuplicateHandle on each of the handles. Then use NtQueryObject on each of them to get the name of the file, then close it.
This isn't how things work on Linux. It keeps the file "alive" as long as there is at least one process using it. Any processes which do not have the file open already will not be able to see it but those that do can keep using it. The file will be deleted when all processes release the file.
https://stackoverflow.com/questions/16764946/what-generates-...
Where most people see that is attempting to mutate a currently running executable. That's forbidden, as it would lead to executing essentially random code. You can replace what file the filename points to, with rename.
There is no such problem. On all the unix-likes, the kernel handles that perfectly naturally.
Think of deleting a file as requesting the file deletion from the kernel rather than directly doing it like in assembly with no os.
When you delete a file, the only thing that happens for sure immediately is no other process can see it in the filesystem, so no new access can be made. To all processes that didn't already have an open file handle, it is effectively deleted and no longer exists.
The contents are not necessarily touched yet, and the filesysyem has not yet necessarily released the occupied inodes and blocks for any other use yet, they are all still tracked as the original file, but now invisible that nothing else except the kernel can see or access.
It stays like that as long as any process anywhere has an open file handle to that file.
Any process with a handle can continue using that handle as normal. If it was opened for write, it can continue to write, seek, read, etc, whatever modes the handle was created with.
The kernel even keeps on coordinating between multiple processes accessing the same now-invisible file. The open file handles aren't just pacifiers, it's still a real file.
But no new file handles can be opened. One by one as processes close file handles, they can no longer open new ones, until the last user has released the last handle.
Only at that point the kernel frees the inodes and blocks in the filesystem making the disk blocks available for new files.
No other processes break, and it's all perfectly graceful and not a problem at all.
For NT not to have that is like some 70's trs-80 stuff.
And holy cow that stuff you just described about querying all other processes...holy cow, not an advertisement for a great, desirable, slick system. "37 easy steps!" It's almost like you were writing a joke to say something is reasonable and then proceed to describe an absolutely laughable process.
Or, you know... the computer has to restart itself for some reason before the file was fully deleted, and you get a fragmented disk.
If I'm asking to delete a file, I want the file deleted. I want to know whether the deletion succeeded or not. I don't want it to secretly hide in a purgatory somewhere.
Is this the year of the Linux desktop already?
If the kernel gets to shut doen gracefully, then there is no problem at all. The file handles are closed when the processed are killed and the filesystem is unmounted in a consistent state.
If the kernel does not get to shut down gracefully (crash or power loss) the filesystem is left no more or less inconsistent than by any other kind of ongoing activity (nothing worse about a pending free-these-blocks vs a pending anything else), and is cleaned up by fsck or by the journal if there is one. Either way the file is finished being deleted on reboot because no processes have open handles and the kenel and the fs know that those blocks are deleted. The last on-disk state of those inodes was that the blocks are not used by any normal file. They are marked pending to be freed but hadn't been freed yet, but now during the mounting process at boot there are no processes that own them, so they are freed. It's no different than the normal process if there were no power loss.
There is no such problem.
As for "some kind of purgatory" and "I want to know it's done now" these imply ignorance of what a multi process operating system is, what it needs to do, the basic job of a kernel, etc. Not just in linux but nt and any other os that allows multiple concurrent processes.
It's the primary job of the kernel to manage exactly such coordination between a process, another process, and the hardware. Slightly virtualizing things like ram and disk is the very job the kernel is there to do, and what makes multiple concurrent processes even posible.
When you delete a file from a process and get your return from that syscall, it IS "really done right now" as far as that process and all other processes are concerned, and "from your point of view" is as "real" as anything ever gets for any process. The fact that some other process can continue reading and writing to a file handle you no longer care about is none of your business any more, and your intent that the file no longer exist in the filesystem so that it could be created again without conflict, or so that it no longer appears in listings, all does happen as you requested, and immediately.
If you had a file named foo, and you needed to delete that because you need to create a directory named foo, you can do that. It happens exactly as you need, even though some other process now has a file handle open to some invisible file that used to be named foo. That other file handle is just not your problem any more. It's as if the other process simply opened a new temp file in some other firectory that has nothing to do with you.
Why is explicitness bad? Would you rather have those weird errors on linux where it's open by default? Or have it where the program author has to say "Yes, this file is fine to be deleted while i'm using it".
"Yes, this file is fine to be deleted while i'm using it"
is fine if all processes play nice, which apparently Windows Defender _does not_. Edit: likely Windows Defender couldn't work if it did? So, in order to consistently delete a file without triggering the file lock, you need to use the work-around.
I'm just guessing here, but wouldn't Windows Defender need to be some privileged process (as it's e.g. an anti-virus) where then this file-locked file deletion process would be impossible to perform? Otherwise, a computer virus could just keep killing the Windows Defender file handler, making it impossible to read its files and keeping Windows Defender from performing its duty.
Alot of the confusion comes from people not understanding the functionality. Delete file means "Delete it now" on windows(ignoring slack space). But on linux it means "Queue up the file to be deleted". Windows also has this, but it's going to be a transacted operation, which is literally called DeleteFileTransacted vs DeleteFile, so the Kernel sees noone is using it and then will delete it.
And honestly, if you go up to any lay person and ask them "What does 'DeleteFile'" do. They'll probably respond it deletes the file. Not queues it up for deleted, but other people can still access it. So I think the windows verbage makes more sense, with another function appending Transacted to it, which signifies it will be done eventually.
The understanding of laypeople in how a multitasking operating system kernel coodinates a graceful teardown of a shared resource, or fails to in the case of Windows, has exactly no bearing on anything. Why isn't it exactly as reasonable to presume that "any lay person" would expect that they can simply issue a delete command and it happens, without having sit there and wonder why they're stuck and go worry about other processes that they didn't write and don't have any knowledge or control over? It is exactly as reasonable. And both are pure meaningless presumption, and don't matter anyway since the understanding of a lay person would be a ridiculous way to design the inner workings of ... anything, definitely including an operating system.
These arguments are swiss cheese.
This doesn't happen for years now due to "opportunistic locks" -- when you open a file being used by an app which support oplocks (i.e.: usually antiviruses), they get a blocking notification and can release the file. They can hold the notification (and stall the requesting application) until they're done, close their handle, and the other app's open succeeds.
But you dont care, obv you dont use it.
I haven’t had a “locked by Defender” error in at least 5 years, and I would say more if I could remember the last time I did.
I’m also developing a(n existing) product that actually uses oplocks, so I’m speaking from experience here.
NTFS likes making sure that disks flush their caches regularly, and congestion caused by cache bloating makes it harder. Getting an nvme (or better, while you can, Optane) SSD for compilation on is a good start for improving your build times.
otoh if you have never encountered Unix, you might be surprised that it's even possible to delete a file currently open by another process.
But... that's what it does?
> someone who works on a C/C++ build toolchain
Pick one. No seriously, tradeoffs have to be made, and I don't think "people who work on build automation" are the intended main use case for Windows Home Edition.
[EDIT] It may have been a ZFS export operation, not exactly an unmount? I can't recall for sure. Point is, Linux made you go find and kill the relevant processes yourself, while FreeBSD made it trivial to override that and do what you needed to do with no further fuss.
Most of the discussion around it has linkrotted. https://lwn.net/Articles/192632/ has some mentions.
Some filesystems implement a less-comprehensive variant that's `umount(2)` with `MNT_FORCE` -- but generally that's only network/FUSE-style ones:
MNT_FORCE (since Linux 2.1.116)
Ask the filesystem to abort pending requests before attempting the
unmount. This may allow the unmount to complete without waiting
for an inaccessible server, but could cause data loss. If, after
aborting requests, some processes still have active references to
the filesystem, the unmount will still fail. As at Linux 4.12,
MNT_FORCE is supported only on the following filesystems: 9p (since
Linux 2.6.16), ceph (since Linux 2.6.34), cifs (since Linux
2.6.12), fuse (since Linux 2.6.16), lustre (since Linux 3.11), and
NFS (since Linux 2.1.116).The ability to run different "operating systems" was neat. The graphics stack was all in user space.
The biggest hope was a selling WindowsNT with Alpha CPUs to the Defense department if memory serves. (Which is why the POSIX parts were added) That never happened.
NT4 was not made to be the best OS for games.
After that Microsoft has cut a lot of neat parts out and bastardized the clean separation between the kernels and user space in order to make the OS faster.
I wish they had branched it "Windows Home" and "Windows Workstation"
It would be a lot of work I guess. They do have Windows Service but I think that it has undergone the same changes.
It was called Windows Me.
Also, the selling point of the Professional editions was and continues to be use in Active Directory and business environments, not developer workstations.
Well, yeah. I sympathize with @bagder here trying to be cross-platform but Windows is just Different than POSIX, and if you try to write everything for Linux then "compatibility shim" your way to Windows support, you're gonna have a Bad Time
A lot of issues disappeared when better abstractions were found on top of POSIX.
If anything, it's even more problematic, because Windows is "wierd" and people go out of their way to create special approaches to handle it. For macOS, too many developers think it's "just posix, ya know, like Linux" and then walk into horrible compatibility edge cases.
AFAIK, only the versions of Windows that included the POSIX subsystem were certified, the last one being NT 4.0. Long time ago.
That's a weird and derogatory way to talk about people who appreciate having a standard which makes it easier to write cross-platform software.
EDIT: To expand on this comment and make it more productive. You're right. If the goal is to have first-class support for both Windows and POSIX-like platforms, the right approach is to have an understanding of what your software needs to do, what the POSIX APIs make easy, and what the Windows APIs make easy, and build abstractions which make sense based on that. But man, do I appreciate that if first-class Windows support isn't top priority, I can support essentially every other widely used platform in the world (including macOS) by just writing against the POSIX API, and I can even get okay-ish Windows support by using a POSIX compatibility layer on Windows. So my point isn't, "People who want to have first-class Windows support but do so through POSIX compatibility shims are doing it right".
It was first known as DEC OSF/1, then Digital UNIX, then Tru64.
Previous to OSF/1, DEC had sold Ultrix, first on VAX, then on MIPS.
https://en.wikipedia.org/wiki/Tru64_UNIX
The wiki says that OSF/1 was first released for MIPS, but that was before my time, and it wasn't supported for long.
I did use Ultrix on MIPS DECStations in college.
When I say "POSIX fanbois" I mean "fanboys" (people that are unreasonably attached to this standard and try to use it everywhere without being level-headed about its usefulness). That probably doesn't include the people who actually wrote the standard, which are all (in my experience) pretty reasonable and realistic about the limitations of things they've created.
This is certainly a better way to put it!
But it's possible that they indeed mostly had the POSIX standard in mind when trying to create their software, possibly because that's what they were developing on (e.g. one of the *nix distros or something compatible) and that's what was available easily.
Support for Windows might have been a bit of an afterthought, or something that was added later. It's still better than nothing, even if not always viable.
[0]https://daniel.haxx.se/blog/wp-content/uploads/2022/11/curl-...
Edit: And there are at least 4 Windows flavours in the list!
There are probably more there. I recognize about half of those names only.
Are you really saying that it's normal to be harder to port some software into Windows than into z/OS?
No, I'm saying that from 89 OSes mentioned on that picture, a lot of them are better at being *nix because they are *nix.
But answering your question, sure! The only good thing in POSIX is that you have easy access to a lot of *nix software. Other than that, POSIX is a spectacularly bad API.
Windows doesn't really care about running *nix software natively, because most of Windows userbase just want and use different things. Therefore, why invest into a bad API? For those wanting to use *nix software on Windows, there is Cygwin or WSL anyway.
How many of them are supported in mainline Curl, aren't POSIX and aren't dead operating systems?
What is a dead operating system anyway, and how is that relevant to the point that Windows is the hardest OS to maintain support for?
* See for instance the config-*.h files in https://github.com/curl/curl/tree/1c567f797bce0befce109bceac...
No longer maintained / barely changing, like MS-DOS, Mac OS 9, Amiga OS (which does occasionally get an update but usually not much in the way of core changes)
It's relevant because Windows is a moving target and the dead operating systems aren't so there's not a lot of support work needed for them nor will there be as much of a user base.
I see Windows, Windows CE, XBox and even MS-DOS on that list.
Mac OS 9
DR DOS
OS/2
VMS
Windows CE
z/OS
MorphOS
Atari FreeMiNT
OS/400
[...]
Actually probably a fourth (EDIT: after looking more closely, make that ~half) or so of the list are not in any way UNIX.
Another comment here mentions NT being full of all sorts of quirks. Such sentiments ignore all sorts of quirks with Linux. For some reason, they're ignored or forgot about because people like digging into the internals of esoteric design choices of Unix tools and the Linux OS.
I find myself fairly OS agnostic having spent about equal times on macOS and Windows and a little less on Linux other than as a programming target. In my experience, Windows is the best these days to work on because I get both Linux and Windows on one machine and OS. macOS and Linux all by itself are too much of a compromise as a Linux and as a desktop OS, respectively, for me.
I am currently working on a cross-platform windowing tool with GLFW. Linux and macOS are by far the problem children because of strange limitations in Cocoa/macOS and because Linux has no "built-in" windowing solution.
> If it's written for linux it can be made to work well with BSD and Mac.
Maybe that's true in a theoretical sense, but it has not been my practical experience with macOS. Too many times have I found I needed a plethora of workarounds on macOS only for the same thing to work flawlessly on Ubuntu.
It doesn't matter WHY, but it is.
> everything from path separators, stupid shells, charsets, to not excepting non-sockets in select, no std libc, ownershipd of memory passed to DLLs, ...
Not having a standard-compliant libc seems really annoying. Also, curl is an IO heavy library. Not having select work as it does on other platforms or not having libc work as expected is going to be really annoying.
Emphasis on library, curl is not just a command line tool. Calling a library compiled with one version of libc (actually msvcrXX.dll) from a program or library compiled with a different version of libc (for instance, msvcr71.dll vs msvcr81.dll) means things like file descriptors (not just FILE structs, but also numeric file descriptors) aren't shared between them.
There are several standard-compliant libc implementations (and C implementations in general) available on Windows, pick any one that you fancy. And why should an OS even ship a default runtime for some random programming language anyhow? Just because it was written in that programming language so it gets a preferential treatment? That's breaking the abstraction layering.
And at runtime, libcurl could find itself using a different libc from the application, so a buffer malloc’d in libc can’t be passed to free() by the app.
Yes, it's something anybody who has been seriously programming for Windows has been aware since forever. Which is why libraries and plugins generally expose FreeX() for every X they allocate and return.
That sounds like a problem that could be solved by not doing that and picking one.
That's a general issue with C plugins/libraries. You cannot even assume that objects are allocated with malloc() because the library might use its own memory allocator, object pool, etc.
That would probably require killing CMD, which would be a big compatibility break. I suspect it could be turned into a shim layer for corporates who need to keep running BAT files.
Not accepting non-sockets in select() .. the native API (WaitForMultipleObjects) is much more flexible, but it doesn't look like select().
libc: require the user to install vcrt like everyone else. Microsoft have actually kind of fixed this with the "universal" runtime: https://learn.microsoft.com/en-us/cpp/windows/universal-crt-... but only recently.
If you're a Windows-first developer, you're probably used to these things, but to non-Windows developers, Windows is strange and annoying.
I tried to port one of our server applications to Windows. I eventually gave up because our service would remove files that were still open. To me, it's crazy that Windows doesn't allow you to do that. This also means you can't use a tool like SSH or SCP. If you accidentally kill the local SCP process while the file is transferring, you need to remotely connect to the destination and kill the remote SCP process to allow that file to be modified again.
Except the APIs you need to use to avoid the 260-character MAX_PATH limit (without depending on both an obscure group policy setting and a setting on the application manifest, and keep in mind that curl is also a library so it cannot control the application manifest). AFAIK, the "\\?\" trick to extend the limit to 32767 characters requires both absolute paths and the use of a backslash (\) as the path separator.
In fact, maybe the fact that a Windows port of libcurl can exist at all means that the Windows BSD socket implementation is useful enough to allow these sort of things.
In its last years it got a POSIX compatibility layer. Before that it was hard to even use C strings — which I presume was considered a feature by the Symbian API designers, but unfortunately they made their design choices in the mid-1990s using a subset of C++ that didn’t age well at all.
(and it happens to have a libcurl port)
Also it is not true. A sibling comment mentions Nintendo Switch OS.
I've worked on a medium sized open-source project (~500kLOC) that was supported on Windows, Linux and MacOS, so I'm not unfamilar with cross-platform support. For us, MacOS was by far the weirdest of the bunch.
One of the complaints was the path separators. We solved that by just consistently using / everywhere internal. Any supplied paths would get converted right away. Not really an issue to write home about IMHO.
It's an HTTP client. Here's 1 of 7 HTTP RFCs https://www.rfc-editor.org/rfc/rfc7230
There are bigger specs like for wifi where it's thousands of pages, but I don't think you can classify a client that implements even half of the HTTP specs as basic.
> curl supports about 26 protocols. We say "about" because it depends on how you count and what you consider to be distinctly different protocols.
Yeah that's what I mean, on the face of it there's not all that much platform specific code should be required for that.
Sure handling all the edge cases of HTTP and whatnot isn't trivial, but almost all of that should be platform neutral so not relevant for this discussion.
Now granted I know HTTP/2 and HTTP/3 are different beasts. But that's why I said it would have been nice with some concrete examples. It's always interesting to learn about issues and pitfalls you've never considered, or similar.
I discovered things about the Windows driver, installer, and networking subsystems and APIs that are best described by pinhead from Hellraiser: “I have such sights to show you.”
No other OS comes close. Definitely not the fruit company one or even commercial Unix (yes Solaris and AIX still live). Most Linux package management is a tire fire but the OS is pretty nice.
I blame backward compatibility coupled with what seems to have been a series of fits of overengineering that now must be carried along as boat anchors.
You must remember, Windows was at its core made for the PC! Which meant random manufacturers get to shove it on their PC and random devs get to write code on it and it was closed source. This meant a lot of apis and the burden of supporting them long term. It was made in the era whe se purchased software in CDs.
The more I learn the internals of windows (it's a hybrid kernel but I mean the stuff close to the kernel not userspace) the more I am finding our a lot of fascinating design decisions that others can learn from. But even in user space, COM and WMI alone would be amazing to have on nix (I think KDE sort of tries for COM).
But from curl's perspective I can see why he'd be frustrated but I truly wonder what the problems are. If you use openssl and basically the same libs as on *nix, could it be the build systems and runtimes (Visual C++?)?
I miss those times.
(As well as bonus "filler" like Weezer and Hover they also cut a few things from the actual installer like some of the alternate sound effects and animated cursors from the floppy version IIRC).
Frankly, I'd count Windows 95 as really being in the CD era, floppy software was getting rare than (although apparently there's a even a 39 disc floppy version of Windows 98 if you're a real masochist), but a couple of years earlier CD-ROMs were still quite niche, although a high end workstation does seem a likely candidate to have one.
- What does Windows get right?
- What's it get miserably wrong?
- Is the trouble that all the other OS's are more POSIX-like and this is the odd one out?
But yes, it's a registry key. It will be a bit hard to make explorer.exe reread that registry key without restarting it, though, since it probably reads the key on startup and caches it.
There are many ways to program Windows.
If you want C or C++, you can use Win32[0] and COM[1]. Of course, the C and C++ standard libraries are also available, within ucrt.dll[2]. Not to mention additional libraries/frameworks like Direct3D, OpenGL, DirectSound, etc.
For .NET, there's several options:
- Windows Forms[3]
- Windows Presentation Foundation (WPF)[4]
- WinUI 3[5] (most recent, but lacking some features)
> For example, let's say 'I want to disable taskbar tab grouping programmatically', how would I know where to look?
There are registry keys and GPO policies[7] (you can use any of the above C/C++/C# APIs to read/write from the registry, but your program will need the appropriate permissions)> However, Windows really is best configured with the GUI (Settings app -> Personalisation -> Taskbar).
[0]: https://learn.microsoft.com/en-us/windows/win32/
[1]: https://learn.microsoft.com/en-us/windows/win32/com/componen...
[2]: https://learn.microsoft.com/en-us/cpp/porting/upgrade-your-c...
[3]: https://learn.microsoft.com/en-us/dotnet/desktop/winforms/ov...
[4]: https://learn.microsoft.com/en-us/dotnet/desktop/wpf/overvie...
[5]: https://microsoft.github.io/microsoft-ui-xaml/
[6]: https://learn.microsoft.com/en-us/powershell/
[7]: https://social.technet.microsoft.com/Forums/en-US/f08bc6bb-a...
A "modern" Windows app can use WinRT, which is a reasonably clean OOP API, from multiple languages including C++. The API is based around coroutines and async/await for concurrency and you can do a lot without ever touching Win32, e.g. there are HTTP clients, file APIs etc all of which are not Win32 and also don't require .NET. Under the hood it's all COM based stuff but you aren't really exposed to that.
Example of what it looks like:
https://github.com/microsoft/Windows-appsample-photo-editor/...
The reason you think that is that once, it was indeed the API of UWP apps and those had various constraints as Microsoft tried to Apple-ify the platform. But they gave up on that a long time ago and got far more relaxed. Now you can mix and match old/new tech. You can ship Win32 apps in the app store, Win32 apps using MSIX, WinRT code using custom installers etc (the "sideloading" toggle switch went away a while ago for up to date Windows 10 machines, it still exists in Windows Server which is a fork of an ancient Win10 branch).
Caveat: some WinRT APIs want you to have "package identity", which (I think??) requires MSIX. This is not different to macOS though, where some APIs require you to have a bundle ID and be code signed. The OS wants to be able to have some stable identifier for an "app" which is allowed to change arbitrarily between versions. On macOS that identity is plumbed through Apple's in-house certificate authority through to a CMS signed CodeDirectory structure in the MachO headers. On Windows it's in some ways a bit simpler, in other ways, more complex - it comes from a combination of your code signing certificate and your package ID. There is an API and cmdlet for granting an app package identity without it being installed via MSIX but for some reason it's limited to developer mode. My guess is that MS will give up on that at some point and let old-style Win32 installers grant package identity too. The MS approach is there for a reason though, because the files installed via MSIX are "tamper-proofed" which prevents other apps from overwriting them. So, establishing the identity of an app installed this way is extremely fast and there's no way to hijack another app's identity by fiddling with its data files. If you look at how macOS does it, it's kind of painted itself into a performance corner by lacking this, the requirements on apps w.r.t. loading data files is very unclear, and they're still changing how they enforce code immutability even in Ventura as a consequence.
C# has an excellent system for native interop ("P/Invoke") if you need to write a program that calls a couple of native functions that aren't available as nuget packages.
> disable taskbar tab grouping programmatically
.. fiddling with windows settings, on the other hand, is kind of a nightmare. Either you identify the registry key or you have to go hunting in an endless maze of APIs.
https://twitter.com/autinerd https://twitter.com/ocdtrekkie
I don't get it
My biggest gripe with Mastodon is just how bad their thread support is. With Twitter, it's easily noticeable which reply belongs to which chain, Mastodon just flattens everything.
edit I found a way. You can use the JS api, like:
https://mastodon.social/@bagder/109432034039353503
becomes,
https://mastodon.social/api/v1/statuses/109432034039353503
which returns the post in json form. Readable without execution.
Opening a socket and issuing a GET call is somehow too difficult on Windows?
Will you entertain the possibility that CURL's architecture is to blame?
It does a lot more than that, because the Internet isn't actually that simple. You should look at the first paragraph of https://curl.se rather than have me rehash it here.
When the codebase depends on POSIX and platform-specific quirks everywhere, putting the blame on the operating system when it's time to port things is hilarious.
I don't see posts like this from the people who had to port Portal 2 to run natively on Linux, as an example. If Portal 2 (a codebase you can safely assume is 1000x more complex) made it fine without the drama, there's no reason CURL can't follow suit (unless the architecture is botched).
Porting a codebase to a specific target is way easier compare to porting it to multi version of the same target, especially the older ones.