Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
I recently asked the question if I could limit bandwidth via a C# WinForms applications much like NetLimiter and NetBalancer. I was told that there's two ways to do this. Either via proper QoS or writing something along the lines of an "NDIS Network Filter Driver". Using QoS isn't the way I want to take. So I've looked up some of the stuff required to write drivers and found some interesting points. Points such as a good understanding of C/C++, because the executed code being very prone to BSODs since it could be run in something called "Kernel mode". I also found a GitHub "dump" which looks interesting and tempts me to investigate and look around in.
As you can see I'm no where near advanced enough to delve into this on a professional level. Ignoring that, what would be a good start to start my adventures into writing drivers to monitor - and further down the line manipulate the network to introduce throttling.
Any help, guides or information that might be of help is always appreciated.
PS: I am unsure as to whether this is (as afore mentioned in a comment to my previous question) too broad a question to be answered on Stack Overflow. If so, where would I go to ask this?
Indeed, this would be too broad. Driver writing is a complicated thing which requires a good understanding of how a computer and the OS works. Also, C# (and .NET itself) indeed isn't available in Kernel Mode, so C/C++ is the preferred way. Although theoretically any unmanaged language (like Pascal) could do, I haven't heard of anyone writing drivers in them. Microsoft's own developer resources are also written with C/C++ in mind.
Which brings us to the question of why you want to do it.
If you need it for work and there's a deadline - forget it. Get someone else who already knows this stuff. Or there might be a library out there that fills the need. Any of these options will be cheaper than your time spent learning all this stuff.
If it's for your own curiosity however - go for it! I'd advise by starting to learn C first. Not C++, that's more complicated and for drivers it will be easier with C anyway. But you can pick up C++ later too, it's good stuff. C++ is mostly compatible with C, so you can start with C and then continue with C++.
In parallel, get a good book about OS design. Not because you want to design an OS, but to understand the basic concepts that it is built upon. You should get a good understanding of things such as Kernel Mode/User Mode, virtual memory, interrupts, process scheduling, etc.
Learning a bit of assembly might be useful too (albeit not required).
Finally, when you feel like you've got a good grasp of the above, head over to MSDN and start reading about driver development. There will be long articles and example programs to get you started. Tweak them and play around in a virtual machine until you get what you need.
And also... read this.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
So I was fiddling around with the Raspberry Pi, and it just kinda came to me that "Where do all these drivers come from". Like specifically for the SNES controllers im using on them....how on earth did someone figure out how to write that.
I know C decently, and C++...ok. But this has always been something I kinda thought about. It's cool because it's low level enough to understand possibly whats going on hardware wise....but also great to learn about the OS.
Where do I start with something like this? Im guessing doing this for windows would be WAYYYY different.
Thanks
It seems to me that there are really two questions here that don't really have a lot to do with each other.
The first is "what does Linux require of device drivers?" That's almost always going to be answered by reading the documentation. Although the device driver documentation may (arguably) be a little less thorough, complete, easy to read, etc., than docs for writing normal programs, it's still pretty decent. Probably the biggest difference from normal code is debugging, which is most often done via simply printing things out with printk.
The other question is something like: "How do you figure out what protocol is (or "protocols are") used by specific hardware like the SNES controller. When you're developing for something like a normal hard drive or keyboard, you can pretty much just follow the documentation. You may (often do, at least in my experience) find that you need to compensate for some bugs in the hardware, but beyond that it's (again) fairly normal programming. The biggest challenge in quite a few of these cases is simply deciding how you want to present the particular device in question to the rest of the system. For something like a hard drive that's generally pretty easy, but for something like a human interface device, it can be a little more challenging (e.g., do you want to present it as itself, or do you want to emulate some existing type of device like a keyboard or mouse?)
For hardware that's not really documented, things can get a little more difficult. The really general purpose tool for looking at logic signals is a logic analyzer. If you have something that uses a well-known hardware interface (e.g., PS/2 keyboard/mouse, USB, SATA) you can find more specialized tools (and/or add-ons for a logic analyzer) that make life quite a bit easier. Something like an NES or SNES controller almost certainly uses a proprietary interface, so for these you probably end up using a logic analyzer. Fortunately, they're also likely to be a pretty narrow, slow interface, so the logic analyzer doesn't need to be terribly fast or support a huge number of channels.
With the logic analyzer you can see all the individual signals, but for a proprietary interface, it's pretty much up to you to figure out which signals do what. In a typical case, you'll have at least a few that are fairly obvious: power, ground, quite possibly a clock, and so on. In quite a few cases, you quickly find that even if it's not publicly documented, it may follow some well-known protocol like I2C, SPI, etc.
Linux Device Drivers is the book you want.
While you wait for the book to arrive, I can tell you that knowing how the hardware works and how the Linux kernel works is only half the battle. You also need to know the hardware level interface for your specific device. Hopefully you can find documentation for this, but that can be difficult.
See this related question for an example of how someone came up with a driver for Linux by watching the commands that came out of the Windows driver:
How are low level device drivers written for Linux?
For Windows, the process is not actually terribly different. All the concepts are still the same, since it is the same hardware. The differences are in the details, of course.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I was wondering how valuable open-source projects are to learn from?
I still consider myself "beginner" due moreso to lack of experience than lack of knowledge- I've read many C/C++ tutorials and taken classes and such, but I just really lack experience. Therefore, even though I understand the major data types and coding techniques, I don't have a solid grasp on what approach to take to use them in my own programming. Therefore, while I continue to read/practice/learn, I have been downloading lots of open-source code (random applications, emulators, games). It is worthwhile looking at them to help learn? I find it extremely interesting, but more often than not just get lost.
Second question, where does one usually start when doing this? Do you hunt down a main() function somewhere? Do you look at headers to see what functions will be available throughout the code and get an idea of what is around to work with?
Please let me know!
R
I personally wouldn't recommend the reading of the source code of open-source projects to a beginner, especially if they're mature projects. It may be overwhelming for a beginner since they tend to be rather large projects with thousands of lines of code, most likely of a non-trivial design.
If you lack experience, then the best way to gain experience is by writing your own programs and taking on your own projects that are of interest to you, in my opinion. You can certainly read other people's code to see "how it's done", but actually trying to implement those ideas yourself in practice does more to help you understand how to write code than just passively reading code. In turn, the gained understanding and experience will allow you to make better sense of other people's code.
It's sort of like math; you may know the formulae, and you can see how mathematicians/teachers/professors/etc. use those formulae, but you won't really understand them until you try them out yourself. Once you do understand them, then the kinds of things mathematicians write will make much more sense.
Try to focus on things you want to do, there's not a lot of point in looking at code for an application that you have no reference point for.
The best place to start would probably be to look at a project like Boost
But formulate a series of application tasks that you'd like to investigate, perhaps graphics, text editing or socket programming... and then work from there.
Getting a good IDE or programmers editor that will help you navigate the code is a major plus.
For example, Emacs + ECTAGS/CEDET/Semantic will help you browse all the functions / classes in a C / C++ project.
I'm agree with #In silico. It's very useful to see other's code, but only when it's a little bit over your level, so that you can learn something. I've seen quite a few projects that were too "over-engineered", so that learning from them when you can't really tell the good from the bad will be a bad idea.
Another thing is to learn from another programmer, when you could ask why he did one way and not another. In this case the difference in levels does not matter.
So I'd suggest programming by yourself, and looking on the other people's code for the same thing after you've tried it. In this way you'll be able to compare the choices you've seen and the decision you've made with someone else (when you don't know a problem in depth, any suggested solution would seem right). You know, In theory, theory and practice are the same. In practice, they are not.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 12 years ago.
Improve this question
I'm a high school student, and I have a decent amount of programming experience (HTML, Javascript, PHP, Actionscript 3.0). I know C++, but unlike the other languages I know, I have never actually made any decent sized projects with it. I am puzzled at what kind of project I should start, as there are so many things you can do with C++.
I just want some experience making something - but right now I don't know what I want to do!
HELP ME!
Find some open source projects and offer your help. You get to see other's code and have a goal on what to develop.
Find something that interests you. That will keep your attention the longest.
Pick something you're either passionate in, or something that might help you at home.
If you do that, then you have a vested interest in it rather than it being just another application.
For me, I wrote a small system to keep track of my customers. Now I know there are any number of applications that do that but I just wanted something small and custom so it really worked for me.
After that, when it was working, I then went back and refactored etc.
I see this question quite often. My reply is always the same. Programming is about scratching an itch. First find something that interests you and doesn't have a solution (or at least a good one). That's the itch.
Next sort out the best solution. It may be C++, .Net, Java or any one of a hundred other languages. The key is to pick the right tool for the job. If you try and push the square language in the round problem you will fail.
Programming is not about any one language. It's about finding the best solution to a problem and implementing it well using the right tools. This is what makes the difference between someone who knows a programming language, and someone who solve problems. The first are a dime a dozen, the second and worth their weight in gold.
Write a bitmap parser and viewer entirely from scratch, don't use any existing libraries. If you want an even bigger challenge, write a jpeg parser, that will require writing a huffman decompression algorithm and all sorts of other goodies.
I did this in java recently for a challenge, the program was rubbish but the amount of things I learnt made it worth while.
You could geek it up and create a complicated RPG (Maybe start with a simple form or console based game to get logic than maybe move on to directx or something).
I made an RPG myself but really never got to directx... yet. It can be fun because the game can be about whatever you want, your imagination is the only limitation. Figuring out the logic is a great way to stimulate your brain and learn new techniques in the process.
Try and find a copy of The OpenGL Programming Guide and have fun with some graphics programming. Old editions can usually be had cheaply.
The examples are all in C, not C++, but its good to get some experience in C too.
Also, see if your school or community hosts programming contests. One of my first large programs was a game for a junior-high level contest (though that was a long, long time ago).
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I need to interview a candidate with over 8 years of experience in Linux using C/C++.
What would be the best way to judge such a candidate?
Do I need to test his understanding of algorithms?
Do I need to test his programming skills by asking to write a program?
How should I test his understanding of Linux?
It depends entirely on what you want him to do. You haven't said anything about the position that you are hiring for but if, say, you want him to write C# then you need him to prove his adaptibility.
Do you need him to write (or modify or bugfix) algorithms? If not, then it is pointless determining how good at them he is.
On the other hand, in order to understand his abilities, you may be better off talking to him about a domain that he is familiar with. You should certainly get him to describe a recent project that he has been involved in, what his contribution was, what the challenges were, what went well, what lessons he learnt.
"Over 8 years of experience in Linux using C/C++" is a fairly vague requirement without reasons for the time length. What are the specific reasons for that time length? Would you prefer more C/C++ experience if some of it were BSD or Solaris or other Unix? Would you prefer less time or a wider experience with different distributions; would you prefer 5 years experience with Red Hat or 7 years experience spanning Red Hat, Debian, SUSE, Gentoo, and others. What are you trying to get from the person you hire, that relates to the amount of time?
The best way to judge a candidate, any candidate, is on how well he can do the job, not how good the qualifications are. You mentioned Lead Developer, owning a product feature and eventually new features. What sort of feature? A highly responsive and adaptive UI? A UI-free recursive data mining calculation? Offline document scanning/indexing code? Custom device drivers?
Basic understanding of algorithms is important, but that can be tested easily in a phone interview. The ability to map out an algorithm for problem solving, and clearly state the reasons for preferring one over another is much more useful, and harder to test.
Test his programming skills by asking to write a program is a fairly useful BS indicator test; there are quite a few people who are adept at slinging manure who can't actually write a line of code. Another useful test is to give him some code with a defect and ask him what's wrong with it, and how he would fix it.
To test his understanding of Linux, I would look at a basic BS test; fire up a Linux box and ask him to perform some basic tasks, including maybe write and compile "Hello world". This will identify the BS artists. Then I would just go with some stock test, showing that he understands the basics of the Linux design; some file system knowledge, some knowledge of tools, ask about how he would add removable device permissions for a user using SE Linux, how he'd configure access to an application that needs elevated privileges so users without those privileges can use the application.
But ultimately, these are all pretty generic ideas; IMHO, it's much more useful to think in terms of "what do we want the candidate to accomplish", than "how do we test basic skills".
Maybe you should focus on what you need. Can he help you? Has he solved problems similar to yours? What are his expectations, what are yours?
I interview people like this all the time. The answer is that no matter how much experience he has, you must prove to yourself that he is capable of the job.
Joel Spolsky is right, hiring badly is destructive to a team and organization. It should be avoided at all costs.
The more I think about it, the more I begin to think good professional developers must be good communicators - in their code and with people. Think of the old saying - the more you know, the more you realise you don't know.
That's not to say you want somebody who isn't confident: but neither do you want someone that is cocky and unwilling to interact with others.
Recently someone asked about whether they should become a programmer in this posting. No matter how a programmer starts out they will likely learn from many mistakes they've made and as a result have an element of humility about themselves and development in general.
A good programmer continues to learn and keeps a relatively open mind.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 7 years ago.
Improve this question
I haven't done C++ for about three years and looking to get back and ready. What is the best way? any open source projects that I might want to look at to recall all the details and be ready for interviews?
I started reading (again) C++ Primer 5th edition but was wondering whether there's more efficient way since I did program in C++ for few years before.
Just wanted to add: Does anyone know about open source projects related to finance? (e.g. servers, fix, etc)
I was facing a similiar situation a while back, and my conclusion was - no matter how many smart books you read nothing will suit you better then practicing.
Find some tutorials or set yourself some simple goals and learn by doing.
Hope that helps
PS. A friend of mine asked me once "How do you eat an elefant? - in small pieces, one at a time"
I'd start in on a real project.
If nothing else, download an open source C++ project that's in the same realm as the jobs you want to target, and start modifying. Practice helps more than anything for being comfortable.
If you're going to focus on reading, or in addition to practice, I'd actually focus on reading books that work more on using C++ well, not necessarily learning C++. Effective C++, More Effective C++, and Effective STL are great for this - you'll learn new things while refreshing your old knowledge. You can always use the primer book as a reference to study things you've forgotten as you read about them elsewhere.
Pick something that you know very little about and attempt to make a program that works with that subject area. For example if you've never done GUI work fire up C++ and try to create a simple paint program in the GUI framework of your choice (Qt, WTL, whatever). Or if you've never worked with a database grab SQLite and create a little app that manages your time. Or better yet, combine all these areas into a larger program.
The key is to force yourself to learn how to do real, practical things and solve problems using the languages paradigms. Books are great to reinforce certain practices but they'll never replace hours of frustration trying to figure out why your pointers aren't pointing where they're supposed to.
If you are good at maths (or statistics, probability, finance, geometry) and want to recall how to build re-useable functions, classes, and templates, you are welcome to help us at mathlibcpp. I recommend it, its good learning. Building a complete library on a large subject is very educatively hard ;) I found a chance to use all OO methods I know in C++, even forced to learn more.
Regarding Fix, there is QuickFAST, a very efficient implementation of the 'Fix for streaming' protocol.
Regarding C++, I would look for something that uses Boost, as it seems to be a premiere library for C++ (QuickFAST uses it to some degree).
Check out http://www.topcoder.com. This is an amazing tool for practicing programming in many different languages (C++, Java, C, C#). You can even win money if you get good at it:)
As with anything, write many programs, (re)read the best books (such as Effective C++, already mentioned). :-)
And ledger is an open source finance program written in C++. (GnuCash is another but written in C.)
Most of KDE is written in C++, albeit with Qt's signal extensions. Probably lots of examples of good code there.