Guess what? The proper thing for any app which saves settings is to read/etc/passwd, and no, it's not to steal your files.
The proper way to get information about the user, such as his name, his home directory, etc is to call the function getpwuid() in a manner like: getpwuid(getuid()), it returns the following struct:
struct passwd {
char *pw_name;/* user name */
char *pw_passwd;/* user password */
uid_t pw_uid;/* user ID */
gid_t pw_gid;/* group ID */
char *pw_gecos;/* real name */
char *pw_dir;/* home directory */
char *pw_shell;/* shell program */
};
Sure it has the user's password listed there (in some format), but this is the proper way to retrieve all the other data also found here. All good applications which save settings per user or try to be more friendly towards the user will call getpwuid() and in turn end up reading/etc/passwd. I have hundreds of programs on my machine like this.
If you think a program reading/etc/passwd is automatically malicious, just remove all your binaries now.
As for reading Firefox files, I'm not sure what it's doing, but Skype does offer Firefox integration right? Surely it's not too hard to imagine it's trying to figure out your configuration and check for conflicting plugins, and the like.
Well I am insane, so you can take my comments with a grain of salt. For code like that, a return smack in the middle is evil, makes the flow more convoluted. Reverse the condition, remove the return, and now have that first if contain the rest of the code. Looks better in the end.
If you take into the account the time it takes to burn all those DVDs, then yes I think the storage media in a vehicle method was beaten a long time ago.
You said it. I'm surprised by how many C/C++ programmers don't know that is the correct way to keep track of the size of an array.
I frequently use the following in programs I write:
#define NUM_ELEMENTS(x) (sizeof(x)/sizeof(x[0]))
Although, how many programmers know this trick, but mistakenly try it when x is a pointer instead of an array?
So what you're saying is that this is a good thing. Since the spam bots will require much more raw horsepower, and thus take it longer to go around spamming the web.
> His new number, which he calls "nullity" solves the 1200 year old problem that niether Newton nor Pythagoras could solve, the problem of zero to the zero power.
Oh please, what's the problem here? Every mathematical equation has an implied identity operation applied to every other one. In the case of multiplication, the identity is 1. Power works as follows: total = identity (1); Multiply total by base exponent amount of times.
Therefor 0 to the 0 power is 1 multiplied by 0 0 amount of times leaving us simply with 1.
> Yeah, last I saw though all the non-windows ports were a bit lacking.
SDL sound and video isn't so great, but I haven't really seen other than that where the non Windows ports were lacking.
> what's your board name?
It hasn't been obvious from my rant? I'm Nach.
>You're telling me that THIS was QAed?
What about the readme tells you it wasn't?
>This is the best you can do cross-platform? "[Parent Directory]" on MAC OS X?!
Mac OS X doesn't have a concept of directories?
>Whoever made this GUI obviously is not a Mac user, and there's no way this could possibly pass as a Mac OS-native application.
That part was made by a Windows user.
>Hell, "About" is in the Help menu! (Oh wait, About is both in Help and in the Application menu. Even worse.)
There's one About for the application, and another about the application it's a frontend for. Although it doesn't do much more than serve as credits.
>The Preferences dialog is actually pretty good.
Well thanks, that's one part I actually wrote myself. But what did you actually find good about it? Just the eye candy?
For simple apps, just pure C or C++. I use GCC for compiling, since it exists everywhere even for DOS and Windows.
For GUI apps or where I need threads or something, Qt is very good.
That's what my test team is for, they're very good at picking up bizare bugs. Like one of my Linux testers noticed if there's a symlink in a directory to a directory below it, the program to get caught in an infinite loop.
A simple fix for that was storing a unique ID per file/dir in a RBTree (std::set) as it sees it and never process something already in the tree. This also resulted in a gain for users of all OSs, since it ensures no file is ever processed twice no matter what crazy technique was used.
My test team tests release candidates on all OSs, and it generally takes less than a week. My development team usually does a lot of unit it testing, and we're good about anticipating oddities, so we rarely uncover any major bugs that require a lot of time or a sizable change to fix.
1) You don't bother to QA your product on Mac/Windows/whatever. (This is the most likely.)
2) Your programs have trivial GUIs and/or you don't give a whit about the quality of the GUI.
3) Your programs are CLIs and have no GUI at all. (Note that if this is the case, they're still probably wrong on DOS, which is quite different from Unix CLIs.)
Wrong on all 3 accounts. See this: http://nsrt.edgeemu.com/forum/viewtopic.php?t=602
One of my codevelopers uses Mac OS X exclusively. Half my test team uses Windows exclusively. My CLI binaries are all for DOS, Windows, Linux, FreeBSD, Mac OS X. It works the same everywhere, even on DOS. The GUI version, I provide binaries for Windows, Linux, and Mac OS X, and the source code so you can compile elsewhere. I'm told it works nicely everywhere, and we even support half a dozen languages some of which you don't all see in one app.
I am a ZSNES developer, and that website is one of my homepages.
I wasn't refering to ZSNES in my question though, however there too I get every now and then people telling us to stop bothering to support a particular OS when support for that OS is already in place and not really changing.
In regard to questions of portability, my team has ported >15% of the assembly in ZSNES to portable C, and really fixed up some of the underlying code. We've also now cleaned it up to the extent that it runs on all x86 OSs we have access too, including Mac OS X. We sent a lot of patches in to Apple in the process because they had major bugs with their development tools such as their assembler not handling a decent percentage of the assembly syntax properly. And we're not done yet, it's a big project to say the least, but we have a party for every 5% of assembly code we port. At this point pretty much all the large side features have been ported to C, and we plan on making headway into some other major components. Our biggest victory no doubt though was porting all the file reading/writing code to C, dealing with files in assembly is just nasty.
I wouldn't blame it solely on Java. Some of it may be that some C++ programming classes today won't even teach the standard file manipulation libraries such as fopen() or std::fstream, but instead teach Win32 API method to open a file.
Regarding 3rd party libaries, depending on some of them is actually a good idea. The zlib library for example is indispensible, hence why almost everything uses it.
As for what Java zealots tell me, just yesterday someone mentioned to me I should switch all my C++ apps over to Java because Java has a string library and I won't have to mess around with char arrays anymore. The new guys aren't even learning what C++ has, demonstrated by C++ having a string library very similar to what Java has, yet they don't even know about it.
And with C++, if one sticks to std::string and the rest of the STL for the most part, all the "it's easy to leak memory" arguments are just a load of FUD. I regularly give my programs a full workout with valgrind and I'm happy to see that they don't leak a single byte of memory. Which in itself is a great reason for portability, valgrind doesn't exist on Windows, yet my Windows users benefit from it because they get solid applications.
I really wish though there would be some way to get the new and/or clueless programmers to realize all of this.
I wrote some complex GUI code with Qt, and found it much easier than any APIs I saw for Windows.
From what I've seen, it requires less work to use Qt.
Overall I see Win32 API is just complex. I once was reading up on MSDN about how one would go about processing stdout from a child application. They presented like a 50 lines solution using many tricky looking calls. I ended up writing functionily identical code using POSIX functions like dup2() and fileno() (which Windows in fact does support right out of the box), in a dozen simple lines, and it was portable to boot.
My frontends are all GPL'd so I just use Qt under the GPL license for them.
For my main apps, some are open some are not, but I generally don't use Qt for them.
>If they won't believe or accept your response when you tell them how little effort portability requires, why should you care about their false perceptions?
It is annoying that users bring it up over and over again despite myself telling them there is no effort involved.
I'm also concerned with the programming community as a whole that we're somehow projecting an image that portability is just too hard.
>For instance, is it a concern that others will believe the non-programmer over you and make decisions which will have a negative impact on you?
Most certainly not. However some of them are programmers in themselves who say they'll contribute if we have a more focused target platform.
It seems apparent to me that somehow the new kids on the block aren't being educated properly.
Slashdot Mirror
The proper way to get information about the user, such as his name, his home directory, etc is to call the function getpwuid() in a manner like: getpwuid(getuid()), it returns the following struct:
Sure it has the user's password listed there (in some format), but this is the proper way to retrieve all the other data also found here. All good applications which save settings per user or try to be more friendly towards the user will call getpwuid() and in turn end up reading
If you think a program reading
As for reading Firefox files, I'm not sure what it's doing, but Skype does offer Firefox integration right? Surely it's not too hard to imagine it's trying to figure out your configuration and check for conflicting plugins, and the like.
That's not needed, but even so, doesn't work for all shells.
Well I am insane, so you can take my comments with a grain of salt. For code like that, a return smack in the middle is evil, makes the flow more convoluted. Reverse the condition, remove the return, and now have that first if contain the rest of the code. Looks better in the end.
If you take into the account the time it takes to burn all those DVDs, then yes I think the storage media in a vehicle method was beaten a long time ago.
You said it. I'm surprised by how many C/C++ programmers don't know that is the correct way to keep track of the size of an array. I frequently use the following in programs I write: #define NUM_ELEMENTS(x) (sizeof(x)/sizeof(x[0])) Although, how many programmers know this trick, but mistakenly try it when x is a pointer instead of an array?
So what you're saying is that this is a good thing. Since the spam bots will require much more raw horsepower, and thus take it longer to go around spamming the web.
> His new number, which he calls "nullity" solves the 1200 year old problem that niether Newton nor Pythagoras could solve, the problem of zero to the zero power.
Oh please, what's the problem here? Every mathematical equation has an implied identity operation applied to every other one. In the case of multiplication, the identity is 1. Power works as follows: total = identity (1); Multiply total by base exponent amount of times.
Therefor 0 to the 0 power is 1 multiplied by 0 0 amount of times leaving us simply with 1.
We got both of the racing games which lacked a gun on the hood and therefor sucked working.
> Yeah, last I saw though all the non-windows ports were a bit lacking.
SDL sound and video isn't so great, but I haven't really seen other than that where the non Windows ports were lacking.
> what's your board name?
It hasn't been obvious from my rant? I'm Nach.
>You're telling me that THIS was QAed?
What about the readme tells you it wasn't?
>This is the best you can do cross-platform? "[Parent Directory]" on MAC OS X?!
Mac OS X doesn't have a concept of directories?
>Whoever made this GUI obviously is not a Mac user, and there's no way this could possibly pass as a Mac OS-native application.
That part was made by a Windows user.
>Hell, "About" is in the Help menu! (Oh wait, About is both in Help and in the Application menu. Even worse.)
There's one About for the application, and another about the application it's a frontend for. Although it doesn't do much more than serve as credits.
>The Preferences dialog is actually pretty good.
Well thanks, that's one part I actually wrote myself. But what did you actually find good about it? Just the eye candy?
For simple apps, just pure C or C++. I use GCC for compiling, since it exists everywhere even for DOS and Windows. For GUI apps or where I need threads or something, Qt is very good.
That's what my test team is for, they're very good at picking up bizare bugs. Like one of my Linux testers noticed if there's a symlink in a directory to a directory below it, the program to get caught in an infinite loop.
A simple fix for that was storing a unique ID per file/dir in a RBTree (std::set) as it sees it and never process something already in the tree. This also resulted in a gain for users of all OSs, since it ensures no file is ever processed twice no matter what crazy technique was used.
My test team tests release candidates on all OSs, and it generally takes less than a week. My development team usually does a lot of unit it testing, and we're good about anticipating oddities, so we rarely uncover any major bugs that require a lot of time or a sizable change to fix.
1) You don't bother to QA your product on Mac/Windows/whatever. (This is the most likely.)
2) Your programs have trivial GUIs and/or you don't give a whit about the quality of the GUI.
3) Your programs are CLIs and have no GUI at all. (Note that if this is the case, they're still probably wrong on DOS, which is quite different from Unix CLIs.)
Wrong on all 3 accounts. See this: http://nsrt.edgeemu.com/forum/viewtopic.php?t=602
One of my codevelopers uses Mac OS X exclusively. Half my test team uses Windows exclusively. My CLI binaries are all for DOS, Windows, Linux, FreeBSD, Mac OS X. It works the same everywhere, even on DOS. The GUI version, I provide binaries for Windows, Linux, and Mac OS X, and the source code so you can compile elsewhere. I'm told it works nicely everywhere, and we even support half a dozen languages some of which you don't all see in one app.
I am a ZSNES developer, and that website is one of my homepages. I wasn't refering to ZSNES in my question though, however there too I get every now and then people telling us to stop bothering to support a particular OS when support for that OS is already in place and not really changing.
In regard to questions of portability, my team has ported >15% of the assembly in ZSNES to portable C, and really fixed up some of the underlying code. We've also now cleaned it up to the extent that it runs on all x86 OSs we have access too, including Mac OS X. We sent a lot of patches in to Apple in the process because they had major bugs with their development tools such as their assembler not handling a decent percentage of the assembly syntax properly. And we're not done yet, it's a big project to say the least, but we have a party for every 5% of assembly code we port. At this point pretty much all the large side features have been ported to C, and we plan on making headway into some other major components. Our biggest victory no doubt though was porting all the file reading/writing code to C, dealing with files in assembly is just nasty.
If you want to see the headway we made with ZSNES, get the latest code from SVN, directions here: http://board.zsnes.com/phpBB2/viewtopic.php?t=7371
I wouldn't blame it solely on Java. Some of it may be that some C++ programming classes today won't even teach the standard file manipulation libraries such as fopen() or std::fstream, but instead teach Win32 API method to open a file.
Regarding 3rd party libaries, depending on some of them is actually a good idea. The zlib library for example is indispensible, hence why almost everything uses it.
As for what Java zealots tell me, just yesterday someone mentioned to me I should switch all my C++ apps over to Java because Java has a string library and I won't have to mess around with char arrays anymore. The new guys aren't even learning what C++ has, demonstrated by C++ having a string library very similar to what Java has, yet they don't even know about it.
And with C++, if one sticks to std::string and the rest of the STL for the most part, all the "it's easy to leak memory" arguments are just a load of FUD. I regularly give my programs a full workout with valgrind and I'm happy to see that they don't leak a single byte of memory. Which in itself is a great reason for portability, valgrind doesn't exist on Windows, yet my Windows users benefit from it because they get solid applications.
I really wish though there would be some way to get the new and/or clueless programmers to realize all of this.
I wrote some complex GUI code with Qt, and found it much easier than any APIs I saw for Windows. From what I've seen, it requires less work to use Qt.
Overall I see Win32 API is just complex. I once was reading up on MSDN about how one would go about processing stdout from a child application. They presented like a 50 lines solution using many tricky looking calls. I ended up writing functionily identical code using POSIX functions like dup2() and fileno() (which Windows in fact does support right out of the box), in a dozen simple lines, and it was portable to boot.
My frontends are all GPL'd so I just use Qt under the GPL license for them. For my main apps, some are open some are not, but I generally don't use Qt for them.
>If they won't believe or accept your response when you tell them how little effort portability requires, why should you care about their false perceptions?
It is annoying that users bring it up over and over again despite myself telling them there is no effort involved.
I'm also concerned with the programming community as a whole that we're somehow projecting an image that portability is just too hard.
>For instance, is it a concern that others will believe the non-programmer over you and make decisions which will have a negative impact on you?
Most certainly not. However some of them are programmers in themselves who say they'll contribute if we have a more focused target platform. It seems apparent to me that somehow the new kids on the block aren't being educated properly.