I find it sad to read that the owner of the bar feels the reason folks in Berlin might be going for the bar is because they're a future-going people... and the reason they're a future-going people is because their past has sucked so much.
Still, it looks like it would be fun to go to such a bar. I'd probably study the machinery (if it's interesting enough) and try to find bugs.
Well, obviously I give a shit. And I'm certain that I ain't all that special (hence the nickname 'fleeb').
Why Ogg?
It doesn't suffer from patent envy.
It provides superior playback-to-bitrate.
'Ogg' is one syllable, 'MP3' is three.
Ah.. about that 'low quality' quip...
Provide me with any reported double-blind aural analysis between MP3 and OGG that shows MP3 as the winner. So far, I have only seen reviews in favor of OGG. And in my own observations OGG does a fine job.
I have yet to enjoy a Verizon Experience that didn't suck in some way.
They don't do a great job of handling my local phone service. They provided extreme discomfort when trying to acquire DSL (through a different carrier, mind you; I've already seen what they do to their own customers), and have not exactly heard wonderful things about their wireless phone service.
Now they have extended this wonderful track record to a 3rd generation wireless internet access?
Likely, they will embitter so many people with their poor service that the technology itself will be labelled 'bad'.
While I appreciate the need to identify competent engineers, most programming projects fail due to poor management, not bad engineering.
If you really want to improve software, focus on better management, not on better engineers. With better management, you will eventually have better engineers without worrying about certification.
Perhaps the IEEE should focus on a certification process for managing projects.
After a little more study, I found the 64-bit stuff is indeed going into the system32 folder, and the 32-bit stuff will be going into the system folder.
It's all kind of ugly in that, generally, when you see 'system32', you're going to think 'oh, that 32 means 32 bits'.
OTOH, it keeps to a kind of consistent logic where the greater-bit-handling stuff is kept in the system32 folder, and the lesser-bit-handling stuff is kept in the system folder. I still find it ugly, though, but I guess they had to figure out something.
The wowexec stuff won't look hacky to your way of looking at things, because they're abandoning 16-bit (according to the original article I was responding to).
I don't think the 64-bit unixes worry about 32-bit. But, when you think about it, thanks to Posix certification and such, you probably don't have to worry about it; you just compile your application to the available libs. At least I *think* that's how it is, but I have no practical experience.
16-bit, 32-bit, 64-bit...
on
MS DOS: A Eulogy
·
· Score: 5, Interesting
With the creation of the 32-bit Windows OSes, Microsoft had these relatively unpleasant hacks involving wowexec and system/system32 folders. I suppose they were relatively necessary (although I'm sure folks here could have thought of a better way, but we have the benefit of hindsight).
Now they're finally leaving 16-bit behind, only to introduce similiar (if not worse) hacks between 32-bit and 64-bit OSes. Instead of following their old design (which at least would have been consistent), they opted to use the system32 folder to hold 64-bit stuff, and to have another folder (is it system64?) hold the 32-bit stuff.
I was active in Charlotte and Asheville, NC, and in Japan (within the US Army).
First pass in Charlotte, I had bought my father a 300 baud modem (couldn't afford the 1200 baud ones available at the time) which he plugged into his Kaypro II... but I got the most use out of it. I was in my early teens, and heavily intrigued with this nifty technology.
For a while, we had to convert binary files to hex (so they were ASCII), then download the ASCII without error checking to convert back to binary again on the other end. It was the worst way imaginable to transmit files.
Eventually, Ward Christensen's (sic?) protocol became available. This is either the precursor or the same protocol that later became known as XModem. This made file transfer significantly easier.
I joined the Army, and moved to Japan. While I was in Japan, I got involved with FidoNet. Our computer club maintained a FidoNet node, communicating mostly with other BBSes in English-speaking Japan.
Eventually, having lost an election to become the system operator of the club's BBS, I started my own using an old Amiga and Citadel. I had tried a variety of BBS software for the Amiga, eventually settling on Citadel because of its emphasis on textual communications over files. I had the most unique BBS in Japan.
Then, I finished my term of service and returned to Charlotte, where I tried to get Machine's Machination running again. I caused a couple of other people to start Citadel BBSes in an area where WWIV seemed to have become the dominant player.
Ah.. WWIV. I spent far too much time on WWIVNet. Eventually, we had a kind of contest where you could vote for various WWIV community members, and see who won at an awards ceremony that was held in some sports bar or something.
I won three awards. The first was for the best TradeWars handle (Fearless Fleeb, flying the Garn Blooie Drekship, establishing Garn Blooie Dreksectors and Garn Blooie Drekports). The next award I won granted me status as the most eloquent user, a title that stunned me. I was asked to give a nice speech, but not having prepared, I did not have much to say (a pity, in retrospect). Most amusingly, however, was finding myself with the third award, voted the most verbose user (where those who asked me to give a speech told me to shut up).
I eventually ran Machine's Machination in Asheville, and for a little while networked with Citanet, but eventually had to take it all down. I wouldn't dream of running one now, with the Internet as it is and all.
But Citadel, from my perspective, had the best user filter available; only those people clever enough to figure out the peculiar user interface could 'join', and those people tended to also be the ones that liked signal over noise. Hence, my BBS of choice.
Perhaps the instructor could find a variety of different open source projects with individual bugs that need to be repaired, and assign these bugs to the students to resolve.
In this way, the student learns to work within the context of a team (the open source project in question), the instructor gets to see how well the student works, and cheating becomes difficult because each student has different problems.
Admittedly, the instructor would have a lot of work cut out for him to assess the difficulty of each assigned bug. The students should receive bugs that aren't so impossible as to make the student feel a failure, yet not so easy as to be ignorable.
However, such work would be about as realistic as you can get in a scholastic setting. You're dealing with real problems that exist in the real world. You'd be working with real people on real projects. And bug-fixing constitutes the majority of what entry-level programmers find themselves doing anyway; it's a great way to learn common coding problems, and by constantly examining other people's code, you may learn their idioms and tricks.
In commercial software, customers drive a demand for new software such that companies are punished for taking the time to try to get the software right. Time and again, when offered the choice to go with software that has been well-written versus software that is poorly written (but available today), the customer will choose what is available today.
You will 'loose' business and people will 'loose' their jobs.
I love a good, loose job. But I only need to ask my significant other to help me out with that.
And if you've created an All You Can Eat Supermarket, it sounds like you've already created a loose business. If it's too loose, though, it might run afowl of the law.
I've heard of people loosing their accounts, which strikes me as a severe security violation. And I honestly feel more people should loose their mind.. get rid of those old, outdated ideas, and explore something new.
I remember loosing a soccer game. It was amazing to see all those people in the stands tripping over themselves to get a score. Very amusing.
Meanwhile, I've been having trouble with the cap on this bottle. I wish I could just lose the cap.
I have an old Zippy the Pinhead comic, in which Bill Griffith did a series of Zippy comics centered around a news article that a guy wearing a Phil Silvers T-shirt was mistaken for wearing a shirt with the Dalai Lama (sic) on it. This happened in Tibet, of course, so certain folks were not at all amused.
The resemblance, apparently, was remarkable.
On a semi-related note, I wonder how freaked out face-blind folks might be about all this.
I'm kind of surprised the article did not recommend that software companies restructure the way they go about handling software projects.
I would imagine some of these hiring problems that I read about here in Slashdot and have seen first-hand would be diminished if, as an industry, we worked more like a surgical team and less like an assembly factory (yes, a The Mythical Man-Month reference).
With such an approach, job qualifications change, making it easier for people to learn appropriate skills on the job while reducing the risk of screwing up a project.
Re:My page DOES use C++
on
Why not Ruby?
·
· Score: 1
Ah...
Minor point of clarification:
Imagine if your web page included client-side C++ instead of client-side Javascript.
Sure, let people choose, but can't we just all standardize behind C++ and get it over with?
Sometimes, we need a scripting language within some other given program. C++ just wouldn't work well, with all its flexbility and power; your standard user out there doesn't want to worry about memory allocation and such. Imagine if your web page incorporated C++ instead of Javascript.
You also wrote:
The language is like a paintbrush. You have to do things a little differently, but you still do them.
I agree that a programming language is much like a paintbrush, but consider that your better artists tend to use a variety of brushes to achieve a given effect. So it goes with computer languages; some languages lend themselves better to solving certain problems than others. As ever, do whatever works best for you.
ObTopic
Personally, I haven't used Ruby because I haven't found a need to, yet. It looks intriguing, but Python seems to be easier to work with, as scripting languages go. But then, that may be because I've gone through Python tutorials and such.
Still, with so few people knowing Ruby, and so many more people knowing Perl or Python, I would sooner incorporate Python or Perl in an application than Ruby. One doesn't perform 14th century chromatic Italian madrigals for a country-western crowd. It just isn't accessible.
If you're selling a product on a CD-ROM, despite the fact that the DLL will be thrown into a compressed cabinet, you would have a strong incentive to keep your binary reduced in size.
Hard drive space may be cheap, but CD-ROM space is somewhat more costly. But then, you may not have this problem if your program isn't that large to begin with.
Furthermore, occasionally you must reduce the size of your executable to allow it to transfer across a network more quickly. For some of the work I do, the binary is usually executed from a networked sharepoint. Bandwidth, therefore, is a strong motivator for me to reduce filesize.
That said, I agree with the bit about the Black Box. I sorta suggested that in my original comment, but you nail the point more clearly than I did.
As for VB... in my dev environment, we're doing everything we can to forget VB. It's a nightmare... evil, right down to its rotten core. Can't localize it easily, can't debug it without putting your legs behind your neck, makes it easy to create truly screwy controls with ugly looking dialogs, and you have to bind to it using COM if you're working with C++ (an ugly problem if you want to work across a network on a machine that hasn't "installed" the VB dll). Just say 'no' to VB. I'm sure there's a 12-step program somewhere <chuckle>.
And now, after having written all this stuff about shared libraries, I just happened to notice my signature, and got to wondering about Mr. Franklin's prescience. Or my own, for that matter, to already be using such a sig.
I apologize for the length of time it's taken me to notice this response.. I'm not exactly good about followups <grin>.
For the sake of clarity, I want to point out that my original comment focuses on my own generation of DLLs. As such, practically by definition, they are documented.. if by nothing else than the fact that I have the source.
I will, however, agree that Microsoft has occasionally managed to provide some unpleasant surprises. For example:
I have a programming constraint that requires my executable to able to work for all Windows systems (greater than 16-bit) off a network share. I may put whatever DLLs I like (within reason) in that network share. If I use STL in VC++ 6.0, the program will no longer work on Win9x systems. Why? Because the version of MSVCRT.dll on your average Win9x system lacks a function call used by VC++ 6.0.
You will note, however, that this doesn't have anything to do with 'undocumented calls to the OS'.
I'm not entirely sure I agree that I am forced to work with the latest Microsoft compiler for each change in OS... unless you mean "in order to take advantage of new APIs within the newer OSes". For all their faults, Microsoft has done a relatively decent job of pointing out which APIs are available for which OS they sell. But you don't have to take my word for that.. you may take a look at MSDN yourself.
So far, it has been my experience that when a DLL changes behavior in a way that causes the executable to crash, the executable is calling the Microsoft API in some undocumented (and perhaps improper) way in the first place. Mind you, Microsoft's documentation has left much to be desired in the past, although they seem to be improving (although they still have issues). Just try and grasp how their lower-level networking API works, for an example of difficult-to-understand (and in some cases downright wrong) documentation.
Also, if you want to try to catch some of those 'undocumented' calls for yourself, you may try viewing your DLL through the dependency walker to see exactly how it's linking. This won't catch COM library calls, but you'll at least get something of an idea of how your program is linking to the various Microsoft DLLs.
When generating your own shared libraries, be it on Linux or Windows, your point is well taken: document your shared library carefully, and avoid using 'undocumented' tricks in your use of shared libraries.
Also, please note.. I hate Microsoft. Despite how pro-Microsoft my comments may seem, I truly dislike the company in general. I sorta believe that, to truly hate Microsoft, you must do at least some programming for their OSes. Then, you may do so with conviction, understanding, and clarity.
I'm probably responding to the phrase Part of the DLL hell is the vast amount of them that are unnecessarily created by people who don't understand when static linking will work just fine.
DLLs have several decent uses, but I'd have to agree that a lot of folks probably just frivolously create them without much thought.
In my own work, I use dynamically linked libraries to provide the following solutions:
Dynamic loading decreases load time
By dynamically loading shared libraries that the executable won't be using that often, I reduce the amount of time it takes to load the binary in question, without having to call a separate executable or something. It's a very nice technique, made easier with Visual C++ 6.0's/delayload:[my.dll] parameter.
Shared binaries across executables reduces hard-drive space consumption
If you have several executables using the same set of routines, putting those same routines in a shared library that's dynamically loaded can reduce the extra bloat for the individual executables. There's a limit, of course.. your results may vary. If you're trying to dynamically share code that's rather tiny, you'll actually waste space instead.
Shared binaries across executables decouples the executable information
Put another way, if you have an error in a shared DLL, fixing that DLL will cause all other executables using that DLL to suddenly work properly (provided, of course, that you didn't change any APIs).
Huge programs become more managable when broken down into dynamically loaded shared executables
If you're working with a truly large executable, it's handy to be able to break things down into separate little binaries. You may create small test programs for those little binaries to aid in testing. This can also help pin-point problems with large works.
I'm sure some folks have other reasons, but these are the most important ones I consider when deciding whether to go with a DLL or a LIB.
I own one of those 'early e-books' mentioned in the article. Specifically, I have one of the early Rocket e-Books. At least two or three other folks in my office also have them.
One of the guys in my office used it to read children's stories to his kids. I've found it relatively handy when reading documents on a train (I can jump from book to book without having to carry all of them). And, of course, there's geek value.
The early Rocket e-Books came with a 'publisher' that allowed you to take HTML content and turn it into e-Book content. It wasn't perfect (couldn't handle frames or tables, as well as some graphics), but was enough.
The current generation of e-Books, as sold by NuvouMedia (sic) fail to give this option; you're stuck having to wait for whatever e-Books folks will make for you.
Further frustrating matters, the library of free material that used to be available through www.Rocket-Library.com was taken off-line several weeks ago, supposedly because folks were publishing copywrited material. I didn't see any copywrited material on that site, but I can't say I was keeping up with the library, either... still, all-in-all, given this evidence, I can't help but believe that the current owners of the e-Book hardware intend to perpetuate the disadvantages of the book instead of siezing the advantages of an e-Book.
I doubt anyone here has heard of it, but if you could ever get hold of an old Hold Paperback called Guerrilla television, you'll find one of the best descriptions of the evolution of information that I've ever had the joy of reading. In it, print is described as a media of control by its very nature. In the evolution of information, control has increasingly been lost to the few to be gained by the many. Consider that Gutenburg's press took control away from priests to give to publishers (or kings, if you will). Similarly, television's centralized control has been usurped by the ubiquity of cameras. And, ultimately, the internet has given the greatest measure of control to the masses.
If the e-Book doesn't permit the kind of freedom found with the internet (or at least approaching such), it will very likely fail.
I find myself somewhat frustrated with the viewpoint that western programmers "discriminate" against other cultures because the culture has too many characters, where "discriminate" implies a political, social, or personal conflict. The problem, frankly, seems more technical in nature to me.
Many operating systems have a design that uses a smaller character set, if for no other reason than to help conserve space. Take your average file system; the character set doesn't permit Unicode characters in most cases, and even the C++ STL doesn't have a spec for streaming files with wchar_t names.
Then consider that you have several evolving programs that have to be modified to use a different character set. From experience, I can tell you that, particularly for complex programs, this is not a trivial job.
Finally, imagine that a political body imposes a deadline on imported programs.. that they must support their new standard by such-and-so a date or it won't be permitted within the country. The Chinese did this, extending the deadline to Sept. 2001. I only found out about this yesterday.
All allocations and assignments of IPv6 address space are made on the basis that the holder of the address space is not to be considered the "owner" of the address space, and that all such allocations and assignments always
remain subject to the current policies and guidelines described in this document. Holders of address space may potentially be required, at some
time in the future, to return their address space and renumber their networks in accordance with the consensus of the Internet community in
ensuring that the goals of aggregation and efficiency continue to be met.
So, for example, someone could force all of Japan to change their IPv6 addresses for "administrative reasons"? I suspect this could get very political; imagine a governing agency of the IPv6 addresses wanted to sock it to a given area of responsibility.
Slashdot Mirror
We are Devo.
I find it sad to read that the owner of the bar feels the reason folks in Berlin might be going for the bar is because they're a future-going people... and the reason they're a future-going people is because their past has sucked so much.
Still, it looks like it would be fun to go to such a bar. I'd probably study the machinery (if it's interesting enough) and try to find bugs.
Whoa, wait a tic... 'bugs' in a bar!?
Never mind.
Why Ogg?
Ah.. about that 'low quality' quip...
Provide me with any reported double-blind aural analysis between MP3 and OGG that shows MP3 as the winner. So far, I have only seen reviews in favor of OGG. And in my own observations OGG does a fine job.
I have yet to enjoy a Verizon Experience that didn't suck in some way.
They don't do a great job of handling my local phone service. They provided extreme discomfort when trying to acquire DSL (through a different carrier, mind you; I've already seen what they do to their own customers), and have not exactly heard wonderful things about their wireless phone service.
Now they have extended this wonderful track record to a 3rd generation wireless internet access?
Likely, they will embitter so many people with their poor service that the technology itself will be labelled 'bad'.
I'm still holding out for Ogg Vorbis. Someday, somebody has to build a recorder and player in Ogg Vorbis instead of MP3.
While I appreciate the need to identify competent engineers, most programming projects fail due to poor management, not bad engineering.
If you really want to improve software, focus on better management, not on better engineers. With better management, you will eventually have better engineers without worrying about certification.
Perhaps the IEEE should focus on a certification process for managing projects.
Gratis!
That's the quote I love!
Thank you very much.
I don't remember it very well, but it was something like:
"Sometimes you just have to roll up the newspaper of justice and say, 'bad dog, bad'."
After a little more study, I found the 64-bit stuff is indeed going into the system32 folder, and the 32-bit stuff will be going into the system folder.
It's all kind of ugly in that, generally, when you see 'system32', you're going to think 'oh, that 32 means 32 bits'.
OTOH, it keeps to a kind of consistent logic where the greater-bit-handling stuff is kept in the system32 folder, and the lesser-bit-handling stuff is kept in the system folder. I still find it ugly, though, but I guess they had to figure out something.
The wowexec stuff won't look hacky to your way of looking at things, because they're abandoning 16-bit (according to the original article I was responding to).
I don't think the 64-bit unixes worry about 32-bit. But, when you think about it, thanks to Posix certification and such, you probably don't have to worry about it; you just compile your application to the available libs. At least I *think* that's how it is, but I have no practical experience.
With the creation of the 32-bit Windows OSes, Microsoft had these relatively unpleasant hacks involving wowexec and system/system32 folders. I suppose they were relatively necessary (although I'm sure folks here could have thought of a better way, but we have the benefit of hindsight).
Now they're finally leaving 16-bit behind, only to introduce similiar (if not worse) hacks between 32-bit and 64-bit OSes. Instead of following their old design (which at least would have been consistent), they opted to use the system32 folder to hold 64-bit stuff, and to have another folder (is it system64?) hold the 32-bit stuff.
Confused yet?
Oh well...
> How does this encourage the Beatles to produce more music this many years later?
Well, maybe with Michael Jackson's experience at coming out of the grave, he might be able to bring back John Lennon.
I was active in Charlotte and Asheville, NC, and in Japan (within the US Army).
First pass in Charlotte, I had bought my father a 300 baud modem (couldn't afford the 1200 baud ones available at the time) which he plugged into his Kaypro II... but I got the most use out of it. I was in my early teens, and heavily intrigued with this nifty technology.
For a while, we had to convert binary files to hex (so they were ASCII), then download the ASCII without error checking to convert back to binary again on the other end. It was the worst way imaginable to transmit files.
Eventually, Ward Christensen's (sic?) protocol became available. This is either the precursor or the same protocol that later became known as XModem. This made file transfer significantly easier.
I joined the Army, and moved to Japan. While I was in Japan, I got involved with FidoNet. Our computer club maintained a FidoNet node, communicating mostly with other BBSes in English-speaking Japan.
Eventually, having lost an election to become the system operator of the club's BBS, I started my own using an old Amiga and Citadel. I had tried a variety of BBS software for the Amiga, eventually settling on Citadel because of its emphasis on textual communications over files. I had the most unique BBS in Japan.
Then, I finished my term of service and returned to Charlotte, where I tried to get Machine's Machination running again. I caused a couple of other people to start Citadel BBSes in an area where WWIV seemed to have become the dominant player.
Ah.. WWIV. I spent far too much time on WWIVNet. Eventually, we had a kind of contest where you could vote for various WWIV community members, and see who won at an awards ceremony that was held in some sports bar or something.
I won three awards. The first was for the best TradeWars handle (Fearless Fleeb, flying the Garn Blooie Drekship, establishing Garn Blooie Dreksectors and Garn Blooie Drekports). The next award I won granted me status as the most eloquent user, a title that stunned me. I was asked to give a nice speech, but not having prepared, I did not have much to say (a pity, in retrospect). Most amusingly, however, was finding myself with the third award, voted the most verbose user (where those who asked me to give a speech told me to shut up).
I eventually ran Machine's Machination in Asheville, and for a little while networked with Citanet, but eventually had to take it all down. I wouldn't dream of running one now, with the Internet as it is and all.
But Citadel, from my perspective, had the best user filter available; only those people clever enough to figure out the peculiar user interface could 'join', and those people tended to also be the ones that liked signal over noise. Hence, my BBS of choice.
Perhaps the instructor could find a variety of different open source projects with individual bugs that need to be repaired, and assign these bugs to the students to resolve.
In this way, the student learns to work within the context of a team (the open source project in question), the instructor gets to see how well the student works, and cheating becomes difficult because each student has different problems.
Admittedly, the instructor would have a lot of work cut out for him to assess the difficulty of each assigned bug. The students should receive bugs that aren't so impossible as to make the student feel a failure, yet not so easy as to be ignorable.
However, such work would be about as realistic as you can get in a scholastic setting. You're dealing with real problems that exist in the real world. You'd be working with real people on real projects. And bug-fixing constitutes the majority of what entry-level programmers find themselves doing anyway; it's a great way to learn common coding problems, and by constantly examining other people's code, you may learn their idioms and tricks.
In commercial software, customers drive a demand for new software such that companies are punished for taking the time to try to get the software right. Time and again, when offered the choice to go with software that has been well-written versus software that is poorly written (but available today), the customer will choose what is available today.
I do not see this changing anytime soon.
*laughing*
You will 'loose' business and people will 'loose' their jobs.
I love a good, loose job. But I only need to ask my significant other to help me out with that.
And if you've created an All You Can Eat Supermarket, it sounds like you've already created a loose business. If it's too loose, though, it might run afowl of the law.
I've heard of people loosing their accounts, which strikes me as a severe security violation. And I honestly feel more people should loose their mind.. get rid of those old, outdated ideas, and explore something new.
I remember loosing a soccer game. It was amazing to see all those people in the stands tripping over themselves to get a score. Very amusing.
Meanwhile, I've been having trouble with the cap on this bottle. I wish I could just lose the cap.
I have an old Zippy the Pinhead comic, in which Bill Griffith did a series of Zippy comics centered around a news article that a guy wearing a Phil Silvers T-shirt was mistaken for wearing a shirt with the Dalai Lama (sic) on it. This happened in Tibet, of course, so certain folks were not at all amused. The resemblance, apparently, was remarkable. On a semi-related note, I wonder how freaked out face-blind folks might be about all this.
I'm kind of surprised the article did not recommend that software companies restructure the way they go about handling software projects.
I would imagine some of these hiring problems that I read about here in Slashdot and have seen first-hand would be diminished if, as an industry, we worked more like a surgical team and less like an assembly factory (yes, a The Mythical Man-Month reference).
With such an approach, job qualifications change, making it easier for people to learn appropriate skills on the job while reducing the risk of screwing up a project.
Ah...
Minor point of clarification:
Imagine if your web page included client-side C++ instead of client-side Javascript.
You wrote:
Sometimes, we need a scripting language within some other given program. C++ just wouldn't work well, with all its flexbility and power; your standard user out there doesn't want to worry about memory allocation and such. Imagine if your web page incorporated C++ instead of Javascript.
You also wrote:
I agree that a programming language is much like a paintbrush, but consider that your better artists tend to use a variety of brushes to achieve a given effect. So it goes with computer languages; some languages lend themselves better to solving certain problems than others. As ever, do whatever works best for you.
ObTopic
Personally, I haven't used Ruby because I haven't found a need to, yet. It looks intriguing, but Python seems to be easier to work with, as scripting languages go. But then, that may be because I've gone through Python tutorials and such.
Still, with so few people knowing Ruby, and so many more people knowing Perl or Python, I would sooner incorporate Python or Perl in an application than Ruby. One doesn't perform 14th century chromatic Italian madrigals for a country-western crowd. It just isn't accessible.
If you're selling a product on a CD-ROM, despite the fact that the DLL will be thrown into a compressed cabinet, you would have a strong incentive to keep your binary reduced in size.
Hard drive space may be cheap, but CD-ROM space is somewhat more costly. But then, you may not have this problem if your program isn't that large to begin with.
Furthermore, occasionally you must reduce the size of your executable to allow it to transfer across a network more quickly. For some of the work I do, the binary is usually executed from a networked sharepoint. Bandwidth, therefore, is a strong motivator for me to reduce filesize.
That said, I agree with the bit about the Black Box. I sorta suggested that in my original comment, but you nail the point more clearly than I did.
As for VB... in my dev environment, we're doing everything we can to forget VB. It's a nightmare... evil, right down to its rotten core. Can't localize it easily, can't debug it without putting your legs behind your neck, makes it easy to create truly screwy controls with ugly looking dialogs, and you have to bind to it using COM if you're working with C++ (an ugly problem if you want to work across a network on a machine that hasn't "installed" the VB dll). Just say 'no' to VB. I'm sure there's a 12-step program somewhere <chuckle> .
And now, after having written all this stuff about shared libraries, I just happened to notice my signature, and got to wondering about Mr. Franklin's prescience. Or my own, for that matter, to already be using such a sig.
I apologize for the length of time it's taken me to notice this response.. I'm not exactly good about followups <grin>.
For the sake of clarity, I want to point out that my original comment focuses on my own generation of DLLs. As such, practically by definition, they are documented.. if by nothing else than the fact that I have the source.
I will, however, agree that Microsoft has occasionally managed to provide some unpleasant surprises. For example:
You will note, however, that this doesn't have anything to do with 'undocumented calls to the OS'.
I'm not entirely sure I agree that I am forced to work with the latest Microsoft compiler for each change in OS... unless you mean "in order to take advantage of new APIs within the newer OSes". For all their faults, Microsoft has done a relatively decent job of pointing out which APIs are available for which OS they sell. But you don't have to take my word for that.. you may take a look at MSDN yourself.
So far, it has been my experience that when a DLL changes behavior in a way that causes the executable to crash, the executable is calling the Microsoft API in some undocumented (and perhaps improper) way in the first place. Mind you, Microsoft's documentation has left much to be desired in the past, although they seem to be improving (although they still have issues). Just try and grasp how their lower-level networking API works, for an example of difficult-to-understand (and in some cases downright wrong) documentation.
Also, if you want to try to catch some of those 'undocumented' calls for yourself, you may try viewing your DLL through the dependency walker to see exactly how it's linking. This won't catch COM library calls, but you'll at least get something of an idea of how your program is linking to the various Microsoft DLLs.
When generating your own shared libraries, be it on Linux or Windows, your point is well taken: document your shared library carefully, and avoid using 'undocumented' tricks in your use of shared libraries.
Also, please note.. I hate Microsoft. Despite how pro-Microsoft my comments may seem, I truly dislike the company in general. I sorta believe that, to truly hate Microsoft, you must do at least some programming for their OSes. Then, you may do so with conviction, understanding, and clarity.
I'm probably responding to the phrase Part of the DLL hell is the vast amount of them that are unnecessarily created by people who don't understand when static linking will work just fine.
DLLs have several decent uses, but I'd have to agree that a lot of folks probably just frivolously create them without much thought.
In my own work, I use dynamically linked libraries to provide the following solutions:
By dynamically loading shared libraries that the executable won't be using that often, I reduce the amount of time it takes to load the binary in question, without having to call a separate executable or something. It's a very nice technique, made easier with Visual C++ 6.0's /delayload:[my.dll] parameter.
If you have several executables using the same set of routines, putting those same routines in a shared library that's dynamically loaded can reduce the extra bloat for the individual executables. There's a limit, of course.. your results may vary. If you're trying to dynamically share code that's rather tiny, you'll actually waste space instead.
Put another way, if you have an error in a shared DLL, fixing that DLL will cause all other executables using that DLL to suddenly work properly (provided, of course, that you didn't change any APIs).
If you're working with a truly large executable, it's handy to be able to break things down into separate little binaries. You may create small test programs for those little binaries to aid in testing. This can also help pin-point problems with large works.
I'm sure some folks have other reasons, but these are the most important ones I consider when deciding whether to go with a DLL or a LIB.
I own one of those 'early e-books' mentioned in the article. Specifically, I have one of the early Rocket e-Books. At least two or three other folks in my office also have them.
One of the guys in my office used it to read children's stories to his kids. I've found it relatively handy when reading documents on a train (I can jump from book to book without having to carry all of them). And, of course, there's geek value.
The early Rocket e-Books came with a 'publisher' that allowed you to take HTML content and turn it into e-Book content. It wasn't perfect (couldn't handle frames or tables, as well as some graphics), but was enough.
The current generation of e-Books, as sold by NuvouMedia (sic) fail to give this option; you're stuck having to wait for whatever e-Books folks will make for you.
Further frustrating matters, the library of free material that used to be available through www.Rocket-Library.com was taken off-line several weeks ago, supposedly because folks were publishing copywrited material. I didn't see any copywrited material on that site, but I can't say I was keeping up with the library, either... still, all-in-all, given this evidence, I can't help but believe that the current owners of the e-Book hardware intend to perpetuate the disadvantages of the book instead of siezing the advantages of an e-Book.
I doubt anyone here has heard of it, but if you could ever get hold of an old Hold Paperback called Guerrilla television, you'll find one of the best descriptions of the evolution of information that I've ever had the joy of reading. In it, print is described as a media of control by its very nature. In the evolution of information, control has increasingly been lost to the few to be gained by the many. Consider that Gutenburg's press took control away from priests to give to publishers (or kings, if you will). Similarly, television's centralized control has been usurped by the ubiquity of cameras. And, ultimately, the internet has given the greatest measure of control to the masses.
If the e-Book doesn't permit the kind of freedom found with the internet (or at least approaching such), it will very likely fail.
I find myself somewhat frustrated with the viewpoint that western programmers "discriminate" against other cultures because the culture has too many characters, where "discriminate" implies a political, social, or personal conflict. The problem, frankly, seems more technical in nature to me.
Many operating systems have a design that uses a smaller character set, if for no other reason than to help conserve space. Take your average file system; the character set doesn't permit Unicode characters in most cases, and even the C++ STL doesn't have a spec for streaming files with wchar_t names.
Then consider that you have several evolving programs that have to be modified to use a different character set. From experience, I can tell you that, particularly for complex programs, this is not a trivial job.
Finally, imagine that a political body imposes a deadline on imported programs.. that they must support their new standard by such-and-so a date or it won't be permitted within the country. The Chinese did this, extending the deadline to Sept. 2001. I only found out about this yesterday.
It doesn't make a job easier.
Follow the link in the original story where the link says 'available for allocation'.
Or just click here.
This is from the IPV6 Policy Document:
So, for example, someone could force all of Japan to change their IPv6 addresses for "administrative reasons"? I suspect this could get very political; imagine a governing agency of the IPv6 addresses wanted to sock it to a given area of responsibility.
Or perhaps I'm not reading this correctly.