241–250 of 349 posts
Earlier quoted context omitted.
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.
Note: https://devblogs.microsoft.com/oldnewthing/20140411-00/?p=12...
And slash. They got it backwards.
From a practical point of view, I find \ to be a much more suitable directory separator than /, for the same reason I think Microsoft's choice for blacklisting characters like ? and : from file names is silly. There are real world use cases [1] for adding the / to file names so it shouldn't be excluded!
Microsoft has used the / for command switches since its inception, based on the way the DECS TOPS-10 (1970) used linker flags; with / already taken, they chose the Next Best Thing which is perfectly fine. When Unix came around a year after the TOPS-10 they used a forward slash for directories for some reason but there's no way one is better than the other.
For what it's worth, Windows accepts forward slashes. Since Windows 1.0, actually, all the way back in 1985. Try it for yourself in your browser[2], open notepad.exe and save a file in A:/test.txt. Your path separator may be represented differently, but / works perfectly fine.
Fun fact: in some locales (Japanese, for example) your path separator isn't even a backslash; the path separator is actually rendered as 0x5c, which corresponds to the Yen symbol in Japanese locales of Windows. In Korean locales, it'll show up as the Won symbol and you'll probably find many other path separator characters in other locales that existed way back in the console code page days.
[1]: https://answers.microsoft.com/en-us/windows/forum/all/forwar...
Coding in linux machine is 10000x easier than Windows.
Seriously, i use Windows because i could play video games after coding. Coding in linux machine is 10000x easier than Windows.
Every time I program on another system I miss Visual Studio.
Counterpoint for this rant (showing it's again not very objective, and just what your or your environment's expectations are): it's easier to cross-compile binaries for Linux (using Clang and a sysroot on Windows) than it is to natively compile on Linux (not using a sysroot, as that is the 'default' flow there) if your environment is mostly Windows already. We do this for one of our products, in fact. The post meanwh…
My counterpoint is simpler: I use some of these tools (like VS Code) because they're better, not because they're open source. Also I don't think Pylance or whatever core extensions being closed source contradicts with the fact majority of VS Code (or vscodium) is open-source. And I don't see anything morally wrong that they want to close source some of their competitive products.
My personal problem with Pylance or ssh tools is that they are not working with VS Code based forks. That means that VS Code is not that open source as it trying to look like. And this is suspicious for me.
Earlier quoted context omitted.
> Windows’ file I/O and process launching is so slow. It's not Windows' fault, rather it's NTFS.
There's some documentation on this in some WSL issues on GitHub, but it's not just NTFS. It's stuff like the broader filesystem architecture's inclusion of pluggable 'filters' (kinda neat, but each layer of them incurs a performance cost) or the way commands on other operating systems depend on caches for certain syscalls that Windows doesn't keep, or keep anything equivalent to. Too tired to go find them atm
https://github.com/Microsoft/WSL/issues/873#issuecomment-425...>
Earlier quoted context omitted.
Not every OS has to be a UNIX clone, we don't need an OS monoculture.
You don't need to implement POSIX in order to not bundle your header files in a 9 GB "SDK" download, which isn't available as a direct URL download and can't be installed without user interaction via the GUI. This is a Microsoft issue, not a Windows issue.
Also I advise to learn about the headless installation flags for Microsoft products.
The post mentions CRLF line end syntax, I don't understand why anyone should bother with it. Use \n only, it works everywhere including Windows. Any modern IDE can handle Unix line endings. The same about file paths, use forward slash (/) everywhere and don't waste your time supporting DOS era standards. I think the core.autocrlf option in Git is more harmful than useful (for example, it can change file hashes and br…