Visual Studio
So, I’ve been doing some work on a network visualisation program called BSOD (Don’t ask), cleaning up code here, tweaking some stuff from there. Anyway I’ve got it running well under Linux. The final thing to do before a new version is released is compile it under windows.
Now, I’ve not seriously used Windows since about 1995. When Windows 95 was released my current computer more or less defined the minimum requirements, and through various events ended up using Linux. So this experience with programming under Windows was….. educational. I’m not unbiased in this; I’m used to doing things under Linux. I’ve been using Visual Studio 2005 under XP.
So, what was the experience like? Well, it wasn’t my favourite experience. Some things don’t work as I expect (Every time I try to use the middle click to paste I realise that no… I have to explicitly copy and paste it). Things are different so thats ok. What did bug me was Visual Studio. People explain to me how great Visual Studio is, but my experience was somewhat… different.
Solutions and Projects confused me. Does a solution hold projects, or do projects hold solutions? Why can’t I have multiple solutions open at once? One for building an external library and one for building the main program? Given two checkouts on the same machine, how can I tell what the path is to the file I have open in any obvious way? (I assume theres some way to find out).
Window’s weird ideas about files being open not being able to be touched is annoying. Especially when visual studio suggests that this is probably due to me using version control (wtf?).
Visual Studio recommends poor programming practises. Wizards produce bad code. One example is the skeleton code it produces when you generate a new console application:
int _tmain(int argc, _TCHAR* argv[])
This uses “_tmain”. Now in C/C++ identifiers that begin with an “_” are reserved for the standard library. Programs should avoid ever using identifiers that start with a “_” so that the standard library can use them for symbols that shouldn’t be leaked into the application. For instance <ctypes.h> on MacOS defines almost every single letter variable with a _ in front of it.
Visual studio doesn’t really try to be a C compiler. But it’s almost insulting to have the compiler tell me that my C program doesn’t conform to the ISO C++ specification. It makes me angry to have the compiler suggest changing portable functions (eg strdup()/snprintf()) to less portable versions. C99 was released 8 years ago, yet Microsoft don’t even mention <inttypes.h> / <stdint.h>. These headers are important for portability for applications that deal with integers of fixed length. Sure VS has it’s own non-portable ways of specifing these, but that just makes the oversight more annoying. The solution so far has been to implement our own <inttypes.h> and <stdint.h> for windows and ship them. Frustrating.
Linux doesn’t really have any one elegant way to describe where the library path, library name(s), and header files are for installed library. Two that spring to mind are pkgconfig, and *-config programs. However despite these rather obvious flaws, I don’t see any way to deal with this in Visual Studio eitherrather you have to add the library name(s), the header search paths, and the library search paths. And surprisingly library names aren’t selectable. Plan9’s solution is to have a “#pragma” that specifies the library to link against. Thus if you #include a header, you automatically end up linking against any library that they use.
Microsoft have said in the past that Linux is based on 30 year old technology. Under Linux things have been tried and tested. If they were found lacking then they have been replaced. Windows however appears to have managed to accumulated bizarre limitations directly inherited from the 16bit days. One example which bit me in the butt was that I can’t malloc() in my program, and then free() it in a library. Why? Because in the 16bit world malloc() allocates out of a pool of memory per DLL and a seperate one from the main program. But the limitations is annoying.
DirectX stuff appears to be complicated and rapidly changing. The code I’ve been playing with was written against DirectX 8. DirectX 8 however appears deprecated. (The documentation discusses it’s support for the new and upcoming “whistler” operating system!). However now it appears difficult to compile code against DirectX 8 now, newer SDK’s are geared more towards DirectX9 and DirectX10.
Many of the key combos I remember from my Turbo C++ days still work. The debugger works much the same way. I enjoyed playing with “Run to Cursor” again after all these years. 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.
I miss the flexibility I feel I lose moving to VS. VS seems to want things done in it’s preferred way. Sure you can override it, but you’re swimming against the current. I miss regular expressions, grep, and sed. For example “Find all references” doesn’t show any context, how do I know which one is the one I want? Why can’t I compare two files to see how they differ like I can with diff(1)?
I feel like I’m in Beijing and I don’t speak the language.
March 1st, 2007 at 11:17 am
“I feel like I’m in Beijing and I don’t speak the language.”
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.
March 13th, 2007 at 3:17 am
I suppose that’s why there are diverse programming languages, IDEs, tools, processes, etc. Can you imagine when the Chinese stops speaking Chinese altogether and adopts English as its native tongue? Will the world be a better place if every body uses the same things, forget about being passionate with one cultural thing over another? I say, let us hear about the good and the bad. If you silence the critics, the bad thing perpetuates, and worse, transforms itself into a bigger monster. I see that happen in small and big projects.
April 20th, 2007 at 1:53 am
The problem is not Visual Studio; it’s your ignorance.
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.
June 12th, 2007 at 12:28 am
> 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.
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.
December 24th, 2007 at 8:01 am
WinMerge has significant weaknesses (it is terribly slow for large directories, and pitiful support for regular expressions — you cannot give it a sed string to apply to one side of the input, for example, which is desperately needed), but it is still generally much better for visual navigation than diff — you cannot seriously navigate diff across thousands of directories in a large tree.
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.