Letters to the editor may be sent via email to cujed@mfi.com, or via the postal service to Letters to the Editor, C/C++ Users Journal, 1601 W. 23rd St., Ste 200, Lawrence, KS 66046-2700.
Dear CUJ:
Microsoft's latest high-end software development tool, Visual C++ Version 5.0, has an interesting and infuriating installation behaviour: it refuses to install the compiler or any of the other tools until and unless Internet Explorer is first installed. The reason given is that this is "necessary" for the InfoViewer, but not only is it not necessary, but the InfoViewer itself is not necessary, nor is the Development Environment of which it is a part; the compiler and other tools can (and often are) used standalone. So far as I know, there is no requirement (other than the installation procedure's arbitrary one) that a development platform even be connected to the Internet!
Microsoft's claim that installation of Internet Explorer is required before installation of the tools (which I have already paid for!) can continue is not only untrue, but is an example of just how far Microsoft is willing to go to get their web browser onto people's computers...whether they want it there or not. I have already paid for Visual C++, but now I am told I cannot install it unless I first install another Microsoft product which I do not want and do not need. I suspect this is legally actionable; I am certain that it is reprehensible.
Incidentally, installation of Visual C++ is the first menu selection on the Visual C++ CDROM; the second claims to allow the user to read the README file. In fact, clicking on this button caused my current web browser (Netscape) to be called up, and a file download initiated, all without asking my consent or offering an opportunity to refuse this connection. I don't know what the file was, how many files were involved, where the file was stored, what else may have been done, or how to remove the file(s). Again, I suspect that Microsoft could be successfully sued over this, and again I find their arrogance repulsive.
I have been a DOS and Windows developer for nearly two decades now, but Microsoft has finally pushed me over the line. Hereafter I will include myself among the growing body of developers who refuse to use Microsoft tools, and will actively work to dissuade others from doing so either.
Sincerely,
Van Wanless
van@seikotsi.comMicrosoft replies:
Thanks for bringing this to our attention, and giving us an opportunity to respond. We'd also like thank Mr. Wanless for his input, he sent in a bug report with virtually identical text on June 6, 1997. He indicated to us at that time that he was going to avail himself of our 30-day refund policy. We are sorry to lose him as a customer.
When examining ways to improve our help and online documentation delivery, our goal was to find the richest, most flexible, and most widely supported medium available. More than a year ago it became obvious that HTML was the technology with the most to offer. We made a strategic decision to move to HTML for all our online help and documentation. With the industry as a whole focusing on tools and facilities for authoring, viewing, and enhancing HTML, this is clearly a way to allow Microsoft, our customers, and ISVs to build the most effective documentation.
Visual C++ 5.0 and the Microsoft Developer Network (MSDN) are the first products to move entirely to HTML; all of our other tools will follow in future releases. We also use a number of ActiveX controls for compression, searching, and UI facilities to provide features comparable with previous releases. Currently the only browser to support all of our requirements is Internet Explorer. Recognizing that some people may not have Internet Explorer, we provide it (free of charge) in the box, and, since it is core to using any of our help or documentation, we require it on installation.
Please note that Internet Explorer is not installed as your default browser, it does not in any way affect your current Internet browser installation, and we do not require you to ever click on the Internet Explorer icon. Internet Explorer is installed solely to provide integrated, rich, and flexible documentation for Visual C++.
As Mr. Wanless notes, the README file is provided in generic HTML, and can be read by any browser. When you click on the README button, all we do is request to open this .HTM file. The default browser, in his case Netscape Navigator, is invoked to display the file. This file is read from the CD at that time, the only "download" that happens is to read the file VCREAD.HTM directly from the CD.
As to Mr. Wanless's request to install only the command-line compilation tools, this is not a common request. While many people choose to use, and not use, various parts of the product, we have found that people prefer simple installation procedures. For example, some customers use Visual C++ with their own editor, or with other tools that they prefer, yet still use our project system, debugger, or other components. We will investigate offering an option to allow the installation of only the command-line portions of the product.
Again we thank Mr. Wanless for his input and hope he reconsiders his use of Microsoft Visual C++.
Chris Williams
Business Unit Manager
Microsoft Visual C++
clwill@Microsoft.com
Dear Mr Burton,
In your letter to the editor in the June 1997 edition of The C/C++ Users Journal, you asked were there very many programmers still surfing the Web at 640x480. You were going to use the answer to that question to decide what resolution you should display screen shots on your web site. I believe that by slightly modifying your question the answer becomes apparent.
If you rephrase the question as, "Do I want my web site to be viewed by programmers that are still using 640x480?" or, even more obviously, "Do I want to drive away programmers that are still using 640x480 so that they do not consider using the services that I am offering?" then clearly you should try to cater for the "pixel challenged" programmer as well.
The best way of doing this is to include both scaled-down and full-size screen shots and let the user choose which one to view. Have the two versions of the screen shots on separate pages and create links to them from your main page. A bit of creative writing in the text on your main page can make the links seem natural, or you could include thumbnail pictures of your screen shots as the links.
By the way, this method also has another advantage that web surfers often appreciate. A significant number of web surfers use modems to surf the web. These users prefer to access pages quickly and will avoid pages that take too long to download. Unfortunately this means that you have to avoid a lot of graphics. By having your graphics on separate pages and letting the user decide whether to look at your graphics then:
a) your page will download faster
b) more people will stop at your page when surfing, and
c) those that do stop will find using your page a more enjoyable experience.
A win-win situation.
Graham Shanks
Chief Software Engineer
GEC Marconi RDS
Fife, Scotland
graham.shanks@gecm.comThe opinions expressed are my own and do not necessarily reflect the views of my employer.
Good advice. — pjp
Dear PJP:
In your July 1997 Editor's Forum, you bemoaned the lack of a shell on Unix that would let you scroll backwards through the command history. At present, there are at least three. The one I use is the GNU project's Bourne Again SHell, or bash. It is a Bourne shell clone with oodles of additional features, one of which is a scrollable command history. It also features an editable command line (in either vi or emacs modes) and filename completion (type in a partial name and hit tab and bash will complete the filename, even if it means searching the path to do so). bash is to sh what JP Software's 4DOS is to COMMAND.COM.
The other two shells are tcsh and zsh. You can think of tcsh as a C shell version of bash, while zsh is another Bourne shell workalike. As far as I know, both also have scrollable command histories, filename completion, editable command lines and more.
Later, your editorial takes on poor Unix-like tools in the DOS world. This is rapidly changing as the Windows NT world gains droves of Unix immigrants who want their tools and NT, too. There are a number of emerging alternatives here, but the one I use is Cygnus Solutions' port of the GNU tools to Win32. This package is still in beta, but it is coming along quite well. It includes the entire compiler and command-line tools suite. The compiler is not only capable of compiling many common Unix packages, it can even recompile itself. I have successfully compiled several nontrivial Unix packages with this toolset, and others have reported easy ports of X11R6.3 and Kerberos 5, to name two exemplars. Perhaps Victor Volkman would like to do an article on these tools?
I am also curious about your views on the flaws of the Unix toolset. I have my own views on this matter, but I can't help but wonder what yours are. Would you care to list them? Also, have you tried the GNU tools? I hate to keep going on about them, but they're definitely the most forward-looking tools around. They are highly backwards compatibile, and they still "feel" like Unix tools, but there are lots of improvements. One example is verbose command line switches: For example, I'm always getting ls's -r and -R options confused, but GNU ls takes -recursive and -reverse as well. Another plus is that most utilities have more verbose usage messages, including one you get to through the common -help switch. I could go on and on, but the bottom line is that the GNU versions of the Unix tools are almost always the most full-featured.
One last thing: I don't know that anyone's ever told you this, but I think the best section in the magazine is We Have Mail. I find your other sections highly useful, but the mail section is special to me for reasons I can't quite put into words. It could be the quantity, it could be the feedback you offer. Maybe it's just the contact it gives me to a diverse range of views and concerns that I normally wouldn't get.
Keep up the good work!
Warren Young
http://www.cyberport.com/~tangent
Dear PJP:
In C++ Users Journal, July 1997 Editor's Forum, you said, in regards to Unix command lines: "And I really miss using the keyboard arrows to flip quickly through commands typed earlier."
Get zsh. When I was last a Unix geek, about two years ago, this was the best replacement shell out there. It not only has arrow key scrolling through previous command lines, but also tab completion of commands and filenames, and a host of programming enhancements (my favorite is a wildcard sequence which recusively expands to a file list). It rocks.
Scott Peter
speter@interactive.dreamworks.com
Dear Mr. Plauger,
Add me to the list of Stone-Age Programmers. You identify the most fundamental flaw that GUI's have — the ability to quickly batch repetitive commands, either as a one-off across a large set of commands, or as regular operational tasks.
The best solution to this problem I have seen is Tcl/Tk. It combines GUI power with a model that splits presentation from implementation. It then encourages implementation in chunks that can be joined together via scripting. I would love to see such a concept adopted into Windows in general. Unfortunately we seem to be heading down the "VB for applications" path.
I must strongly disagree with you about MKS. Nothing is perfect — but you only have to imagine Windows 95/NT without it to forgive any minor sins! Indeed, I am starting to feel rather nauseous at the prospect of not having MKS. And this is from a dedicated VMS hack with limited Unix background! It must be good to have got its hooks into me.
Claude Brown
claude@earthling.net
PJP:
Read your Forum this morning.
I use the DOS prompt, with a DOS editor (Brief) and DOS compiler (Watcom) to do my Windows programming. The Windows interface blows for some things, like just trying to copy a file from some dir to some other dir.
Hey I'm a stone-ager and I'm only 30 years old!
Todd
todd@nwcomputing.comMy editorial really unleashed a host of responses, of which the above is just a sampling. Thanks to all for the information and suggestions — I've got plenty of options to explore now. The rich response underscores my basic observation, that programmers need more than menus and mouse clicks to get the job done. — pjp
Greetings, etc.:
In the August 1997 edition, the article "Portable I/O Drivers," by Jan Kristoffersen, has a major non-portable issue: the assumption that int is identical to short.
There is a growing number of 32-bit embedded processors, hence lots of instances where int is 32 bits. If one uses int while meaning short, a (vulgarism deleted) disaster will probably occur.
As an un-needed aside, i have been bitten by programs going the opposite way — int-32 ported to int-16, i.e. mainframe to real/286-mode PC.
Sincerely,
Stanley F. Taylor
sftaylr@cts.com
Hello,
I just wanted to comment on a letter to C/C++ User's Journal (Cohen, August 1997) and Mr. Plauger's reply.
I have used constant data members on several occasions:
1) On several projects that interfaced to hardware, I would pass the I/O address to the constructor. Since this value should never change, it gets stored in a constant data member.
2) My personal concept of the auto_ptr is that it is a type that owns the section of heap that has been assigned to it. The constructor gets the pointer to the data and then never changes. Copy constructors and assignment operators are not allowed since sharing the ownership would result in the memory getting freed twice. Temporary assignments of the heap contents can be given to regular pointers ("temporary" meaning at the same scope or sub-scope of the auto pointer.)
3) I wrapped a thin class around a semaphore for a project I'm doing in VxWorks. The semaphore ID, used by VxWorks system calls, is stored in a constant member. Thin classes could also be applied to other IPC objects.
These constant values, as Mr. Cohen mentioned, are generated by an automated process. "Real world" data — no matter how constant (e.g. birthdates) — should never be put in constant members.
Richard Neswold
Fermilab neswold@fnal.govYours is a reasonable discipline. I still avoid const member objects, for my own personal stylistic reasons. — pjp
Dear Mr. Plauger:
A minor question regarding your article on the header <valarray>: When iterating through an object of type gslice_array<T>, would it not be more efficient (for most cases) to keep the current index around? For example:
// get the first index k = start; // increment the index for (size_t i =N; 0 < i—; ) k += gs.stride(i), ++idx[i]; if (idx[i] < gs.size()[i]) break; else k -= gs.size()[i] * gs.stride()[i], idx[i] = 0;I suspect that you chose your implementation to simplify the higher-level code.
By the way, thanks for many informative and useful aricles over the years.
Ian Lovejoy
In a word, yes. — pjp