Thank you and greetings from germany!

Eclipse is this lumbering POS that can’t load a new workspace without restarting. I try source level debugging and its a crap shoot whether the damn thing honors break points or not. Find in Files is a pain the butt, won’t save your previous searches, and reminds me of Lotus Notes: spend your time searching for things, rather than doing.

We need a good visual diff navigation tool for mid-sized (& larger) hierarchy trees, which allows reasonably easy chained input filters such as sed or awk or tr or whatever is most appropriate to the user’s current needs, and certainly a good cross-platform tool.

What I meant is, much of the knowledge your refer to is only incidental to an understanding of low-level stuff, and is just an artifact of the architecture in question. I don’t consider those things trivia: rather limitedly useful, particularly when they’re an artifact of a limitation of the architecture in question (such as the segmented memory model).

OTOH, there is other low-level knowledge that is universal and is applicable “anywhere” – the stuff about pointers and filesystems that you mentioned happens to fall into this category. (But there are gradations there as well: understanding FAT is much less useful than understanding inode-based filesystems like FFS and its many descendants.)

At least it doesn’t tell me that my changes were “not relevant” subsequently stubbornly producing a nonworking build from valid source.

> Because solutions aren’t designed for that – see above. You can do exactly what you want with multiple *projects*. Alternatively, you could run two instances of VS, if you insist on separate solutions.

I would say that I’m working on a project, trying to make a solution (singular) consisting of a number of partial solutions (plural). I would most certainly not say that I’m working on a solution, trying to make a project.

> “But it’s almost insulting to have the compiler tell me that my C program doesn’t conform to the ISO C++ specification.”

> Why would a C program necessarily conform to the ISO C++ spec.? They are different languages with different specs. In any case, it isn’t telling you that at all. It is telling you strdup, sprintf, etc. are dangerous. They are: it’s right.

Well… in part because C was a nigh-perfect subset of C++ (and will be again after the next update) and in part because VS itself doesn’t really understand what ISO C++ means.

> “One example which bit me in the butt was that I can’t malloc() in my program, and then free() it in a library.”

> Not true. They share a process heap.

You should try to make UI programs. In VS2005 running on the newest Microsoft technologies like C# and .NET it’s STILL requiring you to access all the UI objects only from the thread that created them. That was relevant in, like, 1985, but could we please get rid of it now?

> It is the most fully featured debugger available, as evidenced by your comment on “run to cursor”, and “bt full”. In Visual Studio you have constant point and click access to the stack trace, as well as locals, watched expressions, etc. In GDB you type incantations such as bt that produce a non-interactive splurge.

I get the feeling you dislike command lines. VS is a debugger with a frontend, GDB is a debugger. If you used a frontend, it should feel (and I can add, does feel) very much the same.

> VS has regexp search.

With fairly usable but nonstandard syntax. It’s quite ok though.

> Use winmerge. As in Linux, a separate tool is required to do this. Winmerge is, needless to say, far better than diff.

I can’t comprehend how you can say a thing like this. I might be using an old version of WinMerge, but all the people I know that want to diff more than one file use a Windows Cygwin port of Unix diff.

Solutions and Projects confuse you? Well look up the answer: solutions contain projects. Naturally, this issue doesn’t arise in the Linux makefile/command-line world because it hasn’t come close to offering decent automatic dependency checking or project management.

“Why can’t I have multiple solutions open at once? One for building an external library and one for building the main program?”

Because solutions aren’t designed for that – see above. You can do exactly what you want with multiple *projects*. Alternatively, you could run two instances of VS, if you insist on separate solutions.

You suggest library handling is worse in Visual Studio, again because you clearly don’t understand Visual Studio’s library handling. You can add libraries to projects, to project settings, or via #pragmas. If you understood this, you wouldn’t have the problem you describe.

“But it’s almost insulting to have the compiler tell me that my C program doesn’t conform to the ISO C++ specification.”

Why would a C program necessarily conform to the ISO C++ spec.? They are different languages with different specs. In any case, it isn’t telling you that at all. It is telling you strdup, sprintf, etc. are dangerous. They are: it’s right.

“One example which bit me in the butt was that I can’t malloc() in my program, and then free() it in a library.”

Not true. They share a process heap.

“I find using “bt full” from gdb to be much more useful than the annoying “watches”/”call stack”/”locals” interface, which appears to be more limited than I remember it being when I was using IDE’s in DOS.”

It is the most fully featured debugger available, as evidenced by your comment on “run to cursor”, and “bt full”. In Visual Studio you have constant point and click access to the stack trace, as well as locals, watched expressions, etc. In GDB you type incantations such as bt that produce a non-interactive splurge. GDB lacks numerous features present in the Visual Studio debugger, as evidenced by your mention of features possessed by DOS(!) IDE’s not present in GDB.

“I miss regular expressions”

VS has regexp search.

“Why can’t I compare two files to see how they differ like I can with diff(1)?”

Use winmerge. As in Linux, a separate tool is required to do this. Winmerge is, needless to say, far better than diff.

No doubt a lot of talented shellcode creators grew up learning a lot of their methods from what was necessary on computers of the day.

Links:

* en.wikipedia.org/wiki/Shellcode
* metasploit.com/shellcode.html
* milw0rm.com/shellcode/

Exactly, and you’re behaving like an american with culture shock. Just because it is *different* doesn’t mean it is bad. Try to soak up the culture and appreciate it without *judging* so much.

I had an argument with someone a while ago that said that “free(3)” wasn’t freeing memory because the pointer still pointed somewhere. It’s that kind of loss of knowledge that really worries me.