Major Linux Problems on the Desktop, 2018 edition
-
@tsaukpaetra said in Major Linux Problems on the Desktop, 2018 edition:
@blakeyrat said in Major Linux Problems on the Desktop, 2018 edition:
That's because INI files have been deprecated since like fucking 1994. Christ.
[Citation Needed]
Raymond Chen over 10 years ago: https://blogs.msdn.microsoft.com/oldnewthing/20071126-00/?p=24383/
ps: Remember deprecation is nothing more or less than a suggestion to not use. It does not inherently mean dropping of support or anything else therefore "It reads my 2018 ini files just perfectly fine too" is not at all suprising.
-
@thecpuwizard said in Major Linux Problems on the Desktop, 2018 edition:
Raymond Chen over 10 years ago: https://blogs.msdn.microsoft.com/
A blog does not a source of deprecation fact make. 😜
Welcome, Slashdot readers. Remember, this Web site is for entertainment purposes only.
-
@blakeyrat Windows should adopt TOML.
-
@tsaukpaetra said in Major Linux Problems on the Desktop, 2018 edition:
@thecpuwizard said in Major Linux Problems on the Desktop, 2018 edition:
Raymond Chen over 10 years ago: https://blogs.msdn.microsoft.com/
A blog does not a source of deprecation fact make. 😜
Welcome, Slashdot readers. Remember, this Web site is for entertainment purposes only.
Butbutbut - Raymond is not just a blog
-
@dcon said in Major Linux Problems on the Desktop, 2018 edition:
@tsaukpaetra said in Major Linux Problems on the Desktop, 2018 edition:
@thecpuwizard said in Major Linux Problems on the Desktop, 2018 edition:
Raymond Chen over 10 years ago: https://blogs.msdn.microsoft.com/
A blog does not a source of deprecation fact make. 😜
Welcome, Slashdot readers. Remember, this Web site is for entertainment purposes only.
Butbutbut - Raymond is not just a blog
And I'm not just an AI, but here we are...
-
@tsaukpaetra said in Major Linux Problems on the Desktop, 2018 edition:
A blog does not a source of deprecation fact make.
If I recommend against doing something, then I have deprecated it. There is no requirement that it be by any specific person. As soon as someone says "I no longer recommend" the word properly applies.
-
@thecpuwizard sure, if we're going by the open-sores philosophy, then any fucking person can make a blog post and next time someone runs into a bug, they can point to the blog post and say, 'RTFM n00b, maybe you should use m$ instead you fucking tool'
-
@bjolling said in Major Linux Problems on the Desktop, 2018 edition:
Just that nobody used those most of the time. And MS marketing, oh my...
Nice there
Marketing names have nothing to do with "versioning ... as braindead as Windows"It's what you get to see when you visit their respective official websites. Also, I've yet to meet anyone who'd tell me they're running say Windows 6.2.
-
@tsaukpaetra said in Major Linux Problems on the Desktop, 2018 edition:
A blog does not a source of deprecation fact make. 😜
How about the MSDN page on the API itself?
Note This function is provided only for compatibility with 16-bit Windows-based applications. Applications should store initialization information in the registry.
Christ.
-
@heterodox said in Major Linux Problems on the Desktop, 2018 edition:
@tsaukpaetra said in Major Linux Problems on the Desktop, 2018 edition:
A blog does not a source of deprecation fact make. 😜
How about the MSDN page on the API itself?
Note This function is provided only for compatibility with 16-bit Windows-based applications. Applications should store initialization information in the registry.
Christ.
See, the problem is, the system that's running this app has a volatile registry, so that's effectively a no-go. If there's a better core windows API call to read user-editable configuration in a file, I'm all ears, and have been all ears since the aforementioned lambasting.
Yet nobody took up the challenge, and so it remains that I use ~60 lines of code that depends on nothing more than the most basic Windows environment, and it works fine, "should store information in the registry" or not.
For the curious, here's my code that I stole from a CodeProject:
/// inireader.h //Courtesy https://www.codeproject.com/articles/10809/a-small-class-to-read-ini-file //With adjustments #ifndef INIREADER_H #define INIREADER_H #include <iostream> using namespace std; class CIniReader { public: CIniReader(char* szFileName); CIniReader(std::string szFileName); int ReadInteger(char* szSection, char* szKey, int iDefaultValue); float ReadFloat(char* szSection, char* szKey, float fltDefaultValue); bool ReadBoolean(char* szSection, char* szKey, bool bolDefaultValue); char* ReadString(char* szSection, char* szKey, const char* szDefaultValue); private: char m_szFileName[255]; }; #endif//INIREADER_H /// inireader.cpp //Courtesy https://www.codeproject.com/articles/10809/a-small-class-to-read-ini-file //With adjustments #include "IniReader.h" #include <iostream> #include <Windows.h> CIniReader::CIniReader(char* szFileName) { memset(m_szFileName, 0x00, 255); memcpy(m_szFileName, szFileName, strlen(szFileName)); } CIniReader::CIniReader(std::string szFileName) { memset(m_szFileName, 0x00, 255); memcpy(m_szFileName, szFileName.c_str(), strlen(szFileName.c_str())); } int CIniReader::ReadInteger(char* szSection, char* szKey, int iDefaultValue) { int iResult = GetPrivateProfileInt(szSection, szKey, iDefaultValue, m_szFileName); return iResult; } float CIniReader::ReadFloat(char* szSection, char* szKey, float fltDefaultValue) { char szResult[255]; char szDefault[255]; float fltResult; sprintf_s(szDefault, "%f", fltDefaultValue); GetPrivateProfileString(szSection, szKey, szDefault, szResult, 255, m_szFileName); fltResult = strtof(szResult,NULL); return fltResult; } bool CIniReader::ReadBoolean(char* szSection, char* szKey, bool bolDefaultValue) { char szResult[255]; char szDefault[255]; bool bolResult; sprintf_s(szDefault, "%s", bolDefaultValue ? "True" : "False"); GetPrivateProfileString(szSection, szKey, szDefault, szResult, 255, m_szFileName); bolResult = (strcmp(szResult, "True") == 0 || strcmp(szResult, "true") == 0) ? true : false; return bolResult; } char* CIniReader::ReadString(char* szSection, char* szKey, const char* szDefaultValue) { char* szResult = new char[255]; memset(szResult, 0x00, 255); GetPrivateProfileString(szSection, szKey, szDefaultValue, szResult, 255, m_szFileName); return szResult; }
Edit: Wait a minute, aren't you repeating yourself, @heterodox ?
-
@blakeyrat said in Major Linux Problems on the Desktop, 2018 edition:
That's because INI files have been deprecated since like fucking 1994. Christ. They've probably been deprecated longer than the concept of "byte-order-marker" has even existed.
Is that why Windows 10 still creates desktop.ini files?
-
@tsaukpaetra said in Major Linux Problems on the Desktop, 2018 edition:
Edit: Wait a minute, aren't you repeating yourself, @heterodox ?
And yet two months later you're still saying [citation needed] when people tell you those APIs are deprecated. Yeah, that is weird, all right.
-
@thecpuwizard said in Major Linux Problems on the Desktop, 2018 edition:
Raymond Chen over 10 years ago: https://blogs.msdn.microsoft.com/oldnewthing/20071126-00/?p=24383/
@blakeyrat promised me 20.
-
@laoc said in Major Linux Problems on the Desktop, 2018 edition:
@blakeyrat promised me 20.
-
@laoc That thread is hilarious. Dumbshit question with dumbshit answers.
-
@heterodox said in Major Linux Problems on the Desktop, 2018 edition:
@tsaukpaetra said in Major Linux Problems on the Desktop, 2018 edition:
Edit: Wait a minute, aren't you repeating yourself, @heterodox ?
And yet two months later you're still saying [citation needed] when people tell you those APIs are deprecated. Yeah, that is weird, all right.
Find me a replacement then, I hereby challenge you.
Sure, it may be noted as "Deprecated" in the docs (yet not in the actual api library definitions ), but if there's no viable replacement, there's nothing to be done, is there? The picosecond I'm provided a real alternatives (in accordance to my stipulations, mentioned above and before), I'll gladly (yea, gleefully!) jump ship.
Edit: And I said that ini files themselves are not deprecated, not the APIs that are being called. Read it again if you don't believe me:
@tsaukpaetra said in Major Linux Problems on the Desktop, 2018 edition:
@blakeyrat said in Major Linux Problems on the Desktop, 2018 edition:
That's because INI files have been deprecated since like fucking 1994. Christ.
[Citation Needed]
I'd like to see documentation that says "INI files are deprecated" from whoever is maintaining the standard. I assume that IETF should have an RFC about it, yeah?
-
@tsaukpaetra said in Major Linux Problems on the Desktop, 2018 edition:
Find me a replacement then, I hereby challenge you.
As far as I know there is no replacement. Configuration APIs belong in an app, they don't belong in the OS. You'll note Linux doesn't have them either (unless, I suppose you want to count things like
fgetpwent
and that has a fixed format). Windows had some routines it happened to use for readingwin.ini
, the developers decided to make them public since they had them anyway, and then they realized that was a bad idea.Sorry to hear about the burden of 60 whole lines of code.
@tsaukpaetra said in Major Linux Problems on the Desktop, 2018 edition:
Edit: And I said that ini files themselves are not deprecated, not the APIs that are being called. Read it again if you don't believe me:
Huh. I would, except :
That's a new one on me. I see the quote in View Raw.
@tsaukpaetra said in Major Linux Problems on the Desktop, 2018 edition:
I'd like to see documentation that says "INI files are deprecated" from whoever is maintaining the standard.
INI files aren't deprecated; @blakeyrat misspoke. The APIs you were using to read them are.
-
@heterodox said in Major Linux Problems on the Desktop, 2018 edition:
INI files aren't deprecated; @blakeyrat misspoke. The APIs you were using to read them are.
Fair enough.
@heterodox said in Major Linux Problems on the Desktop, 2018 edition:
Configuration APIs belong in an app, they don't belong in the OS.
The app doesn't write configuration, and isn't expected to. The only reason I didn't whizbang it off the command line is that some options result in much longer strings than would be reasonable for the environment's input.
@heterodox said in Major Linux Problems on the Desktop, 2018 edition:
Sorry to hear about the burden of 60 whole lines of code.
What burden? That it still works just fine despite having a (hidden, gotta RTFM to find it!) deprecation note? My only burden occurred when Notepad "helpfully" changed the apparent underlying file format without warning or cause. Nobody would ever have known had it not done this.
-
@tsaukpaetra said in Major Linux Problems on the Desktop, 2018 edition:
What burden? That it still works just fine despite having a (hidden, gotta RTFM to find it!) deprecation note? My only burden occurred when Notepad "helpfully" changed the apparent underlying file format without warning or cause. Nobody would ever have known had it not done this.
Ah, I misunderstood and thought that was replacement config-reading code you had to write because you couldn't use the Windows API.
The deprecation warning isn't "hidden". Yes, you've got to RTFM to use the Windows APIs. It explains the parameters (was just looking at them today to figure out what dwStackSize I had to pass to CreateRemoteThread to indicate "I don't fucking care"), it has code samples, it has remarks that describe any hidden "gotchas" or version-specific behavior... it's a lot better than documentation for any other library or platform I've ever used. And that's even given the inevitable deficiencies.
If you're writing code that utilizes the Windows API that is based solely on CodeProject, SO, etc. and you've never even seen the documentation for the relevant Windows API functions... well, frankly, you're and it's shitty practices like that that force Microsoft to cook up as many compatibility shims as they do. Read the fucking manual.
-
@heterodox said in Major Linux Problems on the Desktop, 2018 edition:
Read the fucking manual.
I did, as much as I would expect anyone else to, and couldn't find anything as elegant (and simple) as the currently used offering.
@heterodox said in Major Linux Problems on the Desktop, 2018 edition:
thought that was replacement config-reading code you had to write because you couldn't use the Windows API.
Heh, I might be able to write an ini parser in 60 lines of code, but it would probably be even more WTFy than using a deprecated API. :P
No, my complaint was the opposite: That I would have to write something from scratch to load and parse a user config, or import some ginormous library for no real reason.
-
@tsaukpaetra said in Major Linux Problems on the Desktop, 2018 edition:
No, my complaint was the opposite: That I would have to write something from scratch to load and parse a user config, or import some ginormous library for no real reason.
Them's the breaks. No, really, I get the kind of scenario you're in where you want to minimize dependencies as much as possible and it almost physically hurts to have to "reinvent the wheel" inside your own application. But code to "load and parse a user config" doesn't belong inside an operating system's API; if there's something you find you can co-opt to do that, you can't expect it to be the best, to deal with Unicode, to deal with any other manner of things you might throw at it. At that point, it's not an operating system, it's a platform, like, well... .NET.
Having said that, well... I'd use .NET and XML configuration files. I'm fairly certain on everything since Windows 7 (maybe since Windows Vista?), you'll find a version of the .NET framework baked into the install. Obviously not the latest, but then you don't need the latest.
But then, that's just me.
-
@heterodox said in Major Linux Problems on the Desktop, 2018 edition:
I'd use .NET and XML configuration files.
I would, but then, environment.
@heterodox said in Major Linux Problems on the Desktop, 2018 edition:
a version of the .NET framework baked into the install.
Yes, I do believe I can check the box to include .Net 4.0, which adds ~200Mb to the image, which is 440 Mb at present (plus the server files, background info: This is a server appliance-like image), all to add the ability to read a configuration file in a more "acceptable" manner?
Yeah no thanks. I'll take my "can't read Unicode files (despite Unicode not being used nor needed at all)" inability over a 30% increase in OS size.
And really, this is just a stopgap until I can find time to get ODBC working in Linux with UE4 (a not-so-easy task, if the miles of errors produced when I prodded it a year ago would indicate).
-
@tsaukpaetra There's a TOML library for C. With no dependencies except the standard library.
-
@pie_flavor said in Major Linux Problems on the Desktop, 2018 edition:
@tsaukpaetra There's a TOML library for C. With no dependencies except the standard library.
I'll try it!
.... Maybe on Friday.
-
@tsaukpaetra said in Major Linux Problems on the Desktop, 2018 edition:
[Citation Needed]
Is Raymond Chen authoritative enough for you?
-
@jaloopa said in Major Linux Problems on the Desktop, 2018 edition:
@tsaukpaetra said in Major Linux Problems on the Desktop, 2018 edition:
[Citation Needed]
Is Raymond Chen authoritative enough for you?
Funny, that's the third time that blog has been linked!
Also, no.
-
@heterodox said in Major Linux Problems on the Desktop, 2018 edition:
it's a lot better than documentation for any other library or platform I've ever used.
Willing to bet you never worked with RSX-11 [DEC PDP-11] or VMS [DEC VAX] :)
Seriously, their docs [back in the day when docs were all printed and not electronic] were awesome!
-
sure, if we're going by the open-sores philosophy, then any fucking person can make a blog post and next time someone runs into a bug, they can point to the blog post and say, 'RTFM n00b, maybe you should use m$ instead you fucking tool'
-
@bb36e Raymond Chen is not "any fucking person"
-
@jaloopa does MSDN link to Raymond Chen's blog?
-
@laoc said in Major Linux Problems on the Desktop, 2018 edition:
Is that why Windows 10 still creates desktop.ini files?
That thread is Comedy Gold.
-
@el_heffe said in Major Linux Problems on the Desktop, 2018 edition:
Is that why Windows 10 still creates desktop.ini files?
That thread is Comedy Gold.
When Microsoft support can't differentiate between core OS features and malware any more, lulz ensue.
-
@laoc said in Major Linux Problems on the Desktop, 2018 edition:
When Microsoft support can't differentiate between core OS features and malware any more
Toby Fair, some core OS features ARE malware
-
@bb36e said in Major Linux Problems on the Desktop, 2018 edition:
@jaloopa does MSDN link to Raymond Chen's blog?
Microsoft Hosts it!!!!!! And there are many references to it across the ecosystem both within http:/*.microsoft.com and externally.
-
@thecpuwizard said in Major Linux Problems on the Desktop, 2018 edition:
@heterodox said in Major Linux Problems on the Desktop, 2018 edition:
it's a lot better than documentation for any other library or platform I've ever used.
Willing to bet you never worked with RSX-11 [DEC PDP-11] or VMS [DEC VAX] :)
Seriously, their docs [back in the day when docs were all printed and not electronic] were awesome!
The DEC Ultrix manuals were pretty good too. Pity the OS itself sucked in some critical ways.