211–220 of 349 posts
Earlier quoted context omitted.
Better check those desktop market share numbers.
I suspect if you restrict it to developers the numbers would look very, very different on the stackoverflow survey windows is 41.2%: https://insights.stackoverflow.com/survey/2021#most-popular-...
Earlier quoted context omitted.
> I'm a native Win32 developer, have been one for a few decades, and know quite a few others still using MSVC6 Doesn't that tie you to a really old C runtime, and aren't security holes often found in the C runtime?
It links dynamically to msvcrt.dll which is updated as part of the os. I believe it still gets updates as long as it doesn't break the ABI. Modern vc++ links with the universal CRT which is an independently updated msvcrt distribution.
This what is called in Cognitive Behavioral Therapy "All or Nothing Thinking." Microsoft is a for-profit company. It is pro open-source when it helps them and closed source also when it helps them. I like the new Microsoft which has open sourced a lot of stuff. It's way better than the old closed source regime.
yeah the acceptance of oss is cool but they still ship a lot of weird software and technology... which is fine assuming you can avoid it... but sometimes you can't and then it becomes torturous.
I mostly agree on the VSCode part. They should put it up front in the README, homepage and maybe a info modal/badge whenever a user installs said extension. But genuinely asking, how else would you 'label' VSCode? "A free and open-source code editor with some optional components that are proprietary"?
Earlier quoted context omitted.
https://docs.microsoft.com/en-us/windows-server/administrati...
The command won't help when you don't have the permissions. Or do you just want it to be phrased "not supported for users on normally configured systems"? There, then.
Typical UNIX FOSS rant, not taking into account all the development workflows on Windows.
It doesn't, no. If you are only working with libraries designed for Windows or are linking against binaries, most of the dev issues listed disappear. The point of the article is that the Windows push for open source introduces friction because the way of doing things with established OSS projects is so different.
I think the core.autocrlf option in Git is more harmful than useful (for example, it can change file hashes and break something) and should be removed. An option to warn about unwanted \r characters on commit might be useful though.
Only if you want to be trendchasing rather than letting backwards compatibility take care of itself... I'm a native Win32 developer, have been one for a few decades, and know quite a few others still using MSVC6 because it's fast and enough for what they do. Takes Long file paths: Azure, OpenSearch, and ~90 other open source projects have to document how to enable long file paths on Windows because the default is a ~…
It's incredibly fitting that all the links on that post are 403 Forbidden
nesting windows more than 50 levels deep: https://web.archive.org/web/20110623211503/http://blogs.msdn...
nesting menus more than 25 levels deep: https://web.archive.org/web/20110623211552/http://blogs.msdn...
creating a dialog box with more than 65535 controls: https://web.archive.org/web/20110623211515/http://blogs.msdn...
the maximum number of threads a process can create: https://web.archive.org/web/20110628235212/http://blogs.msdn...
the maximum length of a command line: https://web.archive.org/web/20110707074737/http://blogs.msdn...
the maximum size of an environment block: https://web.archive.org/web/20110623211524/http://blogs.msdn...
the maximum amount of data you can store in the registry: https://web.archive.org/web/20070302025026/http://support.mi... (the live link http://support.microsoft.com/kb/256986 still works perfectly, so here's the view as of ~the post date of the article)
if you have to ask, you can’t afford it: https://web.archive.org/web/20080607185547/http://listserv.l...
Earlier quoted context omitted.
The command won't help when you don't have the permissions. Or do you just want it to be phrased "not supported for users on normally configured systems"? There, then.
Well, time to learn about /J flag.
Earlier quoted context omitted.
It doesn't, no. If you are only working with libraries designed for Windows or are linking against binaries, most of the dev issues listed disappear. The point of the article is that the Windows push for open source introduces friction because the way of doing things with established OSS projects is so different.
Not every OS has to be a UNIX clone, we don't need an OS monoculture.
This is a Microsoft issue, not a Windows issue.