Thanks. At least I know someone makes switches that work. I just looked at Black Box' site. Kinda pricey outta my pocket. Two port switches are $90 (four port $120), plus $20 per cable set.
It's not clear why my Belkins don't work on the RS6000, they're fine on PCs and laptops. They should just be passing scan-codes through (except for the hot key, obviously).
-- Keith
Belkin has a reputation for things that barely work, anymore. Their F5D7230-4 "Wireless G Router" is garbage. It has a very limited bandwidth, and even trying to use one as a hardwired router only gave me around 200 Kb data rate, compared to 3 Mb on a Linksys WRT54G. It may be better than that, but I get the same speed with or without it between my main computer and cable modem. Other than their cables, the only Belkin item that worked like it was supposed to was one of the belkin USB to Ethernet adapters that I use to download the MS patches for the various Windows OS in donated computers before I pass them on to "Vets Helping Vets". It, or the Linksys version save me from having to install a network card to connect to my home network.
-- Service to my country? Been there, Done that, and I\'ve got my DD214 to prove it. Member of DAV #85. Michael A. Terrell Central Florida
I agree. I have a Belkin USB to Serial adapter. It works with my GPS, which is why I got it, but I've tried it with other things and it's a roll of the dice if it will work or not.
I have two Belkin KVMs that I got for free because nobody else would use them. I eventually found out why. They didn't work well. It wasn't that they were broken, they were just poorly designed.
One was a normal 4 port PS2/VGA KVM. It didn't pass the windows keys through. I could forgive that on the idea that maybe it was designed before they existed. But it also didn't handle some key combinations involving ctrl or alt keys.
The other one was a newer KVM that included USB switching. It had 4 USB ports on the front that would also be switched to whatever PC was selected, in addition to the PS2 ports. They had the fool idea of converting the PS2 mouse and PS2 keyboard ports to USB HID devices. It was convenient for wiring because you ran just one USB cable to each PC and you could share the mouse, keyboard, monitor, and up to 4 other USB devices plugged into the front. The problem was that all it did was simulate insertion of the USB devices each time you switched. And it didn't do that well. Every time you switched PCs you had to wait for everything to re-detect. Sometimes the PCs wouldn't detect the switch for a long time, like 30 seconds. The same devices plugged into the PC directly would detect in a couple seconds. Even when the detection worked right you still had to wait 3 or 4 seconds for the switch to happen. I don't understand why they didn't just simulate 4 separate USB keyboards and mice to each of the outgoing ports and bridge the PS2 ports to the selected one. That would completely elimnate the USB detection time.
My opinion of Belkin stuff is that I'll try their products if someone gives them to me for free, but I won't buy anything that says Belkin on it again.
Actually I have a couple belkin branded printer cables and USB cables that seem to work OK. Apparently they couldn't figure out how to screw up wire, connectors, and soldering.
I have piles of surplused printer cables, and most of the branded ones are Belkin. Its odd, in that someone will donate a used printer to the project, and the box will have a half dozen cables. I have about 30 printers to test right now, and several hundred spare cables. Too bad that most of them have molded connectors, I can always use 36 position blue ribbon connectors, and DB-25 connectors on other equipment.
As far as "Free" computer equipment, I have a steady stream coming through my home shop that I repair and give away to disabled Veterans. It gives me something to do, rather than sit around and watch TV all day. :)
-- Service to my country? Been there, Done that, and I\'ve got my DD214 to prove it. Member of DAV #85. Michael A. Terrell Central Florida
Joel Kolstad wrote:
Your suspicions, IMO, are quite accurate. Old Bill learned long ago that it really doesn't matter how the customers do it, so long as they do it with much expense (but not so much to make the effort completely worthless) and that it is done from something that came in a white box with the Microsoft logo on it. In fact, as one CEO of another multi-billion-dollar software pointed out recently at a conference, "...well..if you think about it...it is actually to our advantage that our products are a mess and redundant and confuse our customers. This way they buy more of our stuff."
There is a fight raging over in the C++ moderated group
The problem is that, arguably, the best programmers in the prefer C++ (and assembly). Microsoft's grand plan to trap the minds of the elite won't work if the elite keeps rejecting their poo.
So now they are trying the ultimate. They are actually going around to all the standards bodies that govern languages like C++ (ISO, ECMA) and trying to get these bodies to redefine the syntax and semantics of these languages. They started wooing the top C++ coders and paying them. For example, there is a column that is written by a noted C++ expert who has participated in the standards process, Stan Lippman, called "Pure C++".
Anyhow, the idea is that, if you can't trick the programmers into eating your COM crap, you can at least trick the managers, who will hopefully force the programmers to eat your COM crap. This is why they carefully chose the term "managed" to mean interpreted code - any idiot who manages knows that something that is managed is better than something that is not. Managers conclude..."Let's start using C#. We can't have all this C++ code running amuck!!" What's remarkable is that many, many managers are falling for this dung. How far Microsoft gets is directly proportional to the gullibility of masses.
Luckiliy, there is marked polarization in the circles of experts about what Microsoft is trying to do to C++, and frankly I think, given how many international organizations rely upon C++ in its "pure" form, and mandate its use in critical systems, Microsoft has opened up itself for a government-sponsored lawsuit for false advertising. The results of subverting a programming language like C++ would have enormous financial consequences to the entire software engineering industry.
Nevertheless, objectively speaking, in suppor of the *engineers* at Microsoft, the IDE and C++ compiler proper of VS2005 is unequivocably first-class. If feel sorry for those true programmers at Microsoft who have been forced to silently compromise their principles to produce .NET caca for the rest of us.
-Le Chaud Lapin-
...but a KVM? It passes the keystorkes through to my laptops fine. I have the identical unit at home and it works just fine on Linux/Win2K. It does something to the control keys (alpha-numeric keys are fine) on RS6000.
Issues with wireless routers are well known. It's good to know though, I was thinking about their "Pre-N" wireless routers looked interesting though.
-- Keith
On Sat, 18 Feb 2006 00:37:18 -0800, Le Chaud Lapin wrote: ...
I never got to anything like "C++"; this stopped me: " It supports a static object model that is optimized for the speed and size of its executables. However, it doesn't support runtime modification of the program other than heap allocation."
Well, duh! That's kinda the _point_ of C++, isn't it?
Thanks! Rich
[ See
Well, theoretically a C++ program can just write a source, invoke the compiler and link the object code back to itself. The thing is, we have to be explicit where in the program can be modified and how.
I don't like the C++.net thingy but I don't mind it. After all, C++ is very good at adapting interfaces, isn't it?
Regards, Ben
[ SeeIn article , benben wrote: [....]
If you don't consider the speed issue, the ability to change a variable is as powerful and dangerous as the ability to change instructions.
You could write an emulator for a CPU and point it at your data space. Just by changing the contents of said data space, you have the same effect as changing the contents of code space.
--
--
kensmith@rahul.net forging knowledge
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
But C++ does allow program modification at compile-time, through programmatic code generation with templates. Extending that capability from compile-time to runtime would seem to be an obvious, and not particularly momentous, step. So the fact that C++ currently lacks runtime program modification I would view as a limitation of the current language - rather than to reflect a conscious design decision informed by some deeply-held, overaching philosophy. Moreover a philosophical basis for not supporting this feature would be completely moot. Since C++ has no underlying runtime with which to support dynamic program modification, it's simply inconceivable that C++ could ever support such a feature in a practical way. So any discussion about adding runtime program modification to C++ would - in almost all certainty - be no kind of a discussion at all.
Now the word "limitation" in the paragraph above has a strictly neutral connotation. After all, this limitation may not be one that anyone who uses C++ has ever cared about. But by the same token, it is difficult to see how a limitation that some group of programmers do care about, is ever likely to be a net benefit for a programming language. After all there are at least some current language features in C++ (goto, macros, #defines come to mind) that are widely disdained by many C++ programmers. Yet the fact that C++ does support such unpopular language features probably does not deter large numbers of programmers from writing software in C++. And the explanation is simply that it is quite straightfoward to write a C++ program that simply avoids using these constructs. Likewise, even those adamently opposed to runtime program modification as a practice, could simply refrain from modifying their program at runtime were C++ suddenly (and somewhat magically) able to support such behavior.
And for the benefit of anyone who has dreamt of using runtime program modification in C++, it is certainly legitimate to point out that C++/CLI has such support and that C++ does not. It would be extremely difficult for C++ advocates to criticize such language feature comparisons, precisely because one of the more effective (and quite legitimate) selling points used for years to promote C++ over C as a better programming language, has been to enumerate all of the language features that C++ supports and which C does not.
Greg
[ See
C++ is complex and obscure enough already without adding runtime code modification. Programming should be about producing reliable programs, not playing complex mental games and polishing resumes.
But more importantly, the astonishing virus sensitivity of Windows is largely due to the stack orientation of C-style languages combined with the lack if I/D space separation. Code and data are so mixed up that a stack overflow almost always pokes a hole into executable code, and Microsoft is helpless to prevent it. The Windows attitude is "when in doubt, execute it" when it should be "when in doubt, trap it."
Even a PDP-11 understood that code segments should be read-only, and data segments should be unexecutable, and that code, data, and stack should be in totally disjoint spaces.
None of my ROM-based embedded systems have ever had a virus.
John
[ See
Well, there is a "deeply-held, overaching philosophy". And that is, Self-Modifying Code is Bad. That's why they've gone to such great lengths to separate code space and data space.
SMC might have made sense, back when memory was about a dollar a byte, but nowadays it's Just Bad Practice.
If you want to write a program that writes other programs and runs them as child processes, or even threads, fine, but for a program to modify its own code is like a brain surgeon doing brain surgery on himself - It's just plain STOOPID.
Thanks, Rich
[ SeeIt all depends on what runtime code modification means.
Even for the idea of directly modifying the machine code there are some uses. As a Windows programmer (or former Windows programmer) two techniques, now history, but might be applicable on other platforms, come to mind: one technique to uninstall a running program by creating a helper process dynamically (the problem then was that the helper process could not be an ordinary executable file, otherwise how to delete that), and second a very efficient technique for associating a C++ object with a Windows API-level window (dynamically creating message forwarding stubs with C++ object pointer hardcoded -- IIRC this was used by Borland's ObjectWindows framework, and anyway, I used it myself (of course nowadays your automatic malware detection would run wild!)).
Now such techniques may be history, at least in Windows, but Java and C# have demonstrated the practical benefit of having full-blown introspection factilities in a language. With introspection you don't actually modify the machine code -- at least not in a way visible to the programmer -- but when you call something via introspection you're achieving the _effect_ of self-modification, albeit in a runtime-checked way.
And at the introspection level, we have dynamically generated proxies, especially for marshaling/unmarshaling, and we have facilities for implementing cross-cutting concerns such as e.g. security checking or logging for every public member function of an interface (the old-days C++ solution to the latter, in Windows, was the "COM interceptor" piece of self-modifying machine code...).
None of that can, AFAIC, be implemented in a practical way in pure standard C++.
Perhaps the original comment about C++/CLI allowing self-modification referred to something like that; anyway, even though I find the C++/CLI idea of ^ language extension instead of special smart pointer and other pure C++ wrappers less than ideal, I don't think statements made from the pro C++/CLI camp should be discussed purely from the point of view of the worst context-free interpretation possible.
--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
And yet, almost every systems uses it. In the form of dynamically linked objects.
If code and data space are rigorously separate, how do you dynamically load something. To dynamically load an object, you read the file as data, patch up the pointers as data, and then execute it.
Modifying code that is being executed is generally not a good idea. But generating code, and then executing it? I can think of a number of special cases where it would be a valid optimization technique -- not too portable:-), of course, but not everyone needs portability. (My graphics routines for the original IBM PC used this technique. Rather than encomber the loops with if's and such, I generated the exact code for the loop for each request.)
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34 [ See
There we go, discarding the incredibly rich history of LISP systems. LISP programs were modifying themselves with new code in perfectly safe ways, and with garbage collection, before you were born (I'm guessing).
[ See
I generally agree with your comment on SMC but when I read Greg's post it seemed to me that he wasn't talking about *self*-modifying code as much as code generation and execution a la "eval", which is extremely useful in certain circumstances.
It does seem to me, though, that crossing the boundary between compile-link-run and interpreted or JITed code is one that fundamentally changes the nature (or rather culture) of a language. One of the reasons I prefer C++ over competing and closely related languages such as C# and Java (and maybe C++/CLI) is that I can develop everything from a device driver all the way up to very high-level applications in the same environment. C++ may not be the absolute best at any one task but, as far as I'm concerned, it's the best if you're regularly working across all vertical layers of software development. (I have to exclude web/browser software development since I have no experience with that).
Andrew
kanze wrote: a space.
You let the operating system do it.
[ See
To be fair, that's stretching things a little. It's actually the loader that reads the file and performs all the fixups. On a secure OS this would run at a higher privilege than user code, which would not be able to modify code pages nor execute data pages.
Which is what I think most people understand by self-modifying code. I vaguely remember people doing this way back and it always seemed to cause too many problems to be worth it.
Writing your own jitter is pretty cool.
When you're using an interpretted language there's also a useful technique that involves creating test strings containing the new code you want to execute and passing it to the interpreter. You'll still find a lot of this done by people who write SQL server stored procedures.
[ See
You load the executable part (machine instructions) into a code segment, request a stack segment, and load any data into, well, a data segment. Prudent programming suggests that the data segment not include actual pointers, ie, it should be impossible for data to crash code.
That's called a "compiler." It run and generates a code image as data, usually saved to disk. Then someone requests that file to be loaded as an executable, and it becomes code. It is run in execute-only space, and the OS restricts its runtime priviliges. Well, a good OS anyhow.
"Overlays" were common when memory was expensive, before the atrocity of virtual memory was unleashed on the world. They were (usually) relocatable bits of code that could be loaded and executed as needed, sort of like DLLs.
All this was figured out decades ago, but they forgot to tell Bill.
John
[ SeeIn article , PeteK writes
Possibly because you notice the times when it causes problems. Back in the early 80s my Forth implementation for a Z80 machine used self modification in several places and by doing so reduced the footprint by about 10%, that saving was critical on a system which only had 32K to start with. Of course the code was not re-entrant nor was it thread safe but the former was not an issue because this was very low level code and the latter was just not going to happen.
The point is that self-modifying code is strongly coupled to the underlying machine and should only be used as an optimisation in extremis. It would be rare for it to be useful today.
--
Francis Glassborow ACCU
Author of \'You Can Do It!\' see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.