This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
How does a debugger work?
I'm trying to learn more about debuggers. I know the basics of debugging in general and some low level details on windows. But I would like to learn more about the details of how debugging is implemented. Like hardware and software interrupts on windows, linux, OSX and how can a debugger be attached to a running process, and so on.
I am not asking for an answer. All I'd like to get from you is some papers, books, links where I could learn more about this topic.
Thank you for your time.
Since nobody posted an answer I'll just post what I found in case someone else will need it.
I strongly suggest the book "How Debuggers Work: Algorithms, Data Structures, and Architecture" ( Jonathan B. Rosenberg, description ).
There is also a great paper on implementing a debugger "A Survey of Support For Implementing Debuggers" (paper).
There are also some blogs and more detailed papers, but these two really helped me out.
Related
This question already has answers here:
How to learn the Joy of Autotools? [closed]
(2 answers)
Closed 7 years ago.
There are automake, autoconf, autoscan, autoheader and maybe others that I don't know about. If I want to understand and use these tools, which should be the learning order? Which should be learned first? I read the man and info page, but those pages don't give me any clear clue. I can't grab the big picture from those pages.
Can anyone give me a simple explanation (maybe with example) regarding the learning order (assuming I understand C code and a little of Makefile)?
If you understand autoconf/automake and have a basic idea about libtool you don't need to know the rest.
Apart from the sites Etan mentioned there is a book (https://www.sourceware.org/autobook/ ), it is quite dated but still a useful tutorial-like introduction.
I also suggest to look at existing projects that uses autotools.
This is a two-part question:
I was wondering if anyone knew of any FREE tools/applications to design visual applications of memory stacks? Of which would include stack information (e.g. stack pointers, return addresses, variables, frame pointers...). I've heard Multi (Green Hills) might do this, but when I've checked their website it didn't seem as if they offered such a feature. If you can't think of a program that can do what I'm asking, then I would benefit from the best image you can find that includes stack information (I've Googled "memory stack images," but they are all very different looking).
I'm completely new to the C programming language and am trying to do the above. As such, a consequence of my first question is how do I find out all the stack information for me to put into a visual format? I'm doing this for a class assignment and believe that GDB might be able to accomplish this. I'm still learning how to use GDB (have read a couple of guides already), so if anyone knows how to use it to find out all the variables, return addresses, pointers, and so forth for each step in a program executing through each stack frame, that would be awesome. If you know another tool that can accomplish this simply however, then I'd be open to hearing about it and how to use it.
Thanks so much!
Note: I found some similar questions addressed on this site, but must of them either weren't answered or were vaguely answered. I hope someone out there has a few minutes to detail an explanation, particularly for question 2.
Operating System: Linux (Ubuntu)
Programming Language: C
A couple of points:
Basically you need a means to walk the stack
This is very platform dependent and it depends on the os and the hardware platform you are using. It looks like you are using linux. For windows there are native API's available
I assume this is for c programs, so you need to understand the C calling conventions (how are the parameters are put on the stack, where the return address is stored and so on
In addition there might be additional difficulties if ASLR is active.
For linux several APIs exist. One of them is
[http://pages.cs.wisc.edu/~bart/DynStackwalker.pdf][1]
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 8 years ago.
Improve this question
I will start developing my next desktop application in about a month. In the past I have delivered functional software that hasn't wowed anyone, including myself, in the usability or aesthetics department.
Does anybody know of any resources or guides or even books that could showcase examples of good design in desktop software?
There seems to be a lot of resources for web apps, but such resources for desktop applications are rather slim.
I enjoyed these dot net rocks tv videos by Mark Miller on The Science of a Great User Experience really got me thinking about good ui:
http://www.dnrtv.com/default.aspx?showNum=112
http://www.dnrtv.com/default.aspx?showNum=123
Where you can really make a difference with GUI design is if you are addressing a difficult to understand concept in a GUI.
When you are doing that, creativity is critical. When dealing with complex hardware configurations (something I had to do a lot, but probably doesn't apply to you), I've had good luck going to tech manuals and tech support people and trying to completely understand the problem. Then I took the methods they used to show me (diagrams from the manuals, whiteboard drawings, etc) and tried to code them into a GUI.
Had a couple massive successes with this.
Iteration is also critical. Prototype something quickly then beg everyone you see to try it. Ask them to solve a problem, then watch where they go first and watch what they have problems with.
Address every problem and stumbling block.
Don't be afraid to throw it all away and start over, it was only prototype code.
Separate your GUI from your implementation so that you can swap out the GUI if you find a better approach.
If you want to concentrate on just one feature, have a look at ITunes' search box which filters as you type. Other software may have had this before, but this was I think the first place I encountered it.
The difference between this and classic search was an eye opener for me in terms of readability.
Auto-complete which you see in so many places is another one. I'd recommend IntelliJ IDEA for the way it took auto-completion which emacs, Visual studio etc had for ages and added autocompletion for variable names and method names in a manner which almost seemed psychic the first time you encountered it.
You can look at Thirteen23 Experiences
To make things usable, you need to make sure that you follow existing conventions for your target platform and application type.
For example, if you're developing a Windows App you'd better make sure that control-c copies, control-v pastes, control-s saves, etc. The File menu better be the leftmost item in the menu bar, and the Help menu better by the rightmost item.
If you don't follow existing conventions, users are going to get annoyed with your application very quickly.
Google for HIG. Human Interface Guidelines typically include lots of research into best-practice in user interfaces, and explain in great detail how to design each aspect of a program. Also, have a google for "user-interface hall of shame" or something like that.
In this question I mentioned GUI bloopers. Part of great design is knowing what makes bad design and why. It is actually a great book, although I don't know how much of it is available on the website.
You can check case studys on websites of GUI companys. I fund few at www.puzzlehead.com
Check there and also other sites.
This question already has answers here:
Closed 14 years ago.
Anyone have experience with algorithmic trading (like stocks)? Any good services to use to get quotes and to make trades?
I had a freelance project that used Interactive Brokers, which provided both a proprietary API as well as a FIX-based one. The proprietary API is somewhat painful to use (and they probably can't change it much, for compatibility), but you can easily code a "translation layer" to make it much more pleasant. I haven't tried the FIX-based API, so no comments there.
And yes, I reopened the question. I happen to think it's a fair question to ask.
I know TradeStation is pretty popular.
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
Back in the days of Unix, you couldn't even close a software without reading the man page first. Then came Mac and Windows with consistent menu layout and keyboard shortcuts, but you still saw paper user manuals shipped in the shrinkwrap box, which described each and every single operation possible in the app. After the Internet, help files became html documents.
Nowadays with Web 2.0 applications, you hardly see the Help. Even if it's there, they simply describe some specific tasks. In other words, the apps are relying more on the common sense or don't-make-me-think factor of the user base.
Years ago Microsoft came up with a concept called Inductive User Interface, which basically tells programmers to put in instructions on the apps itself, but I am not sure how popular that idea is.
Are help files, user manuals, and context sensitive online help with F1 key dead? Have I failed if user could not find out what to do from the UI? If not, what degree of help should I provide? (both for desktop and web app)
EDIT: How does documentation/help file mesh with agile development methods? For example, should the developers think twice before UI changes that may obsolete a bunch of screenshots?
Three notes on help:
F1 / stand-alone context-sensitive help was always doomed. It was hidden by default, and so the people who most needed it were least likely to read it. There was hope at one time that we would be able to train users to always hit F1 when they ran into trouble, but too many applications without useful context-sensitive help... combined with too many bizarre help interfaces... pretty much killed this.
Manuals are as important now as they ever were. Not so many printed manuals anymore, but online manuals are better than ever. The proliferation of wiki-as-a-manual systems has helped here, reducing the up-front cost of creating good online documentation. Of course, plenty of people just don't read...
The beauty of using web pages as an application interface is that you can combine useful context-sensitive help with the UI, removing the barrier for novices and others who otherwise couldn't be bothered to look for relevant information when they get stuck.
Of course, there are still plenty of apps, even online apps, designed with obtuse interfaces and a tiny little help icon in a corner somewhere, presumably hoping that the latter mitigates the former. Pity them.
No way. You look at the amount of documentation and training and marketing expenditure even MS puts up.. you'll get your answer.
Try using someone else's product, and you will learn the true value of documentation - I'm learning Godiagrams right now.. :)
So I can say without a doubt.. NO and it never will.. no matter how intuitive user interfaces get.. beyond a certain size, you will need help and training. But by understanding the user and what he needs to get done, you could design it such that the time he/she needs to learn the system to do his/her routine tasks is minimal.
Have I failed if user could not find out what to do from the UI?
If not, what degree of help should I provide? (both for desktop and web app)
They should be able to use your your app to do basic things from the UI. eg say for an image editor, they should be able to create a new image, and draw some lines then save it just by looking at the UI.
This is best done by following common layouts (like having new, open and save under file in the menubar, and using the standard open and save dialogs).
The same goes for webapps, people exspect to be able to do the basic stuff without having to read the docs, but for more advanced features people will still read the docs. (eg most pople will read the docs for say BB code, or markdown at least sometimes, but they expect to be able to post without having to know them)
Are help files, user manuals, and context sensitive online help with F1 key dead?
They still have their place. People will use them to learn about how to best use various features, for example markdown or bbcode, or how to use filters to get certain effects in an image editor.
I've been incorporating context-sensitive screencasts into my applications. I've found this helps non-technical users grasp the application quickly, without asking for live help.
The Idiot/Dummy books must be doing quite well. Imagine if the standard application help was as good as those books. The standard F1 help for a lot of apps is just awful.
Is help dead? No, but some of it should be taken out and shot.