Ok, let's try this reply again (I'm on a windows box now, so maybe this works) You stated the one reason for elitism is that C++ programmers think more pain == better engineer. My original comment is aimed at your oversimplification of the situation. (Chris Maunder)Because C++ is harder to learn to use than VB/C#, so programmers like to feel that because they have gone through more pain they are "better". It's the 'anything that hurts you makes you stronger' mentality. What I was trying to say was: more pain == more experience == better able to fix problems == a better programmer. Where is the contradiction? Do you disagree with the above statement? Please don't use sophistry Chris, of course the two statements are contradictory when taken out of context of the paragraph they are in. One of the best engineers I know doesn't have a "new" car, he built it himself. Hardly the same as your analogy, and he does treat _some_ sloppy programmers with disdain, as do I, whether they happen to use VB or not. Is that elitism, or pride in your work? ;P mfg, Mick

Oh come on Chris! do you really think that elitism is the reason VB/VB programmers is treated with disdain in 100% of cases? It's not a case of more pain == better at all. If you have the basic groundings in programming, then the tool you use to implement your project is immaterial. From that point of view, core skills are more important. Core skills are aqcuired through experience. There are _no_ shortcuts to experience. IMO, VB encourages programmers to be lazy, pure and simple. If you have experianced a little "pain", then you are more likely to be able to fix the problem yourself. Microsoft are attempting to create a generation of spoon-fed programmers, and that can't be good for anyone. I've worked with good programmers and bad programmers, the language they used was usually irrelevant. But the best programmers _can_ fix their own cars, to borrow your analogy. You use the right tool for the right job because each language has its place, but VB can foster false expectations.

Hi Jim, just a couple of points about your shell lock-up problems This happens to me on my Win2K machine (but not too often), and not just in Visual Studio. When explorer locks-up, ctrl_alt_del to task manager, kill the explorer process. (you should get a blank desktop). Then from the file menu in task manager, run explorer.exe (file/run/--->type explorer) This brings up a default explorer shell which will allow you to carry on without rebooting. Also sometimes when you close down Visual Studio afterwards you can't run a new copy. If you get this, go to task manager (again), and look for any remnants of visual studio (can't remember exactly because this one hasn't happened to me for a while, but the macro-engine part if MSVC doesn't terminate correctly, so kill this process, then everything should be OK). Hope this helps :) The spec. said "customer wants to get to the top of the mountain". Nobody asked why.

I have to agree with the end result, but maybe the original intentions were good. Unfortunately there is a great gulf between what Microsoft say they will deliver, and what actually ships. But as long as they have customers, this won't change. I did like what you said about Microsoft first creating a problem, then offering a solution. Look at NT, start off with a clean architecture, then bloat it to death later. I mean, they even boast about the amount of lines of code in their products as if more is better. I'm going now, before I get flambeed.

About the last thing you were going to comment on, but didn't. I agree with another comment posted earlier that it may be hiding too much and keeping the programmer too much in the dark. Would it be something along the lines of. "RAD" tools and philosophies, and other techniques to take the "pain" out of programming only serve to dumb-down the programmer. This is not a good thing. Supplying a wizard so a tyro can knock up a GUI-based wordprocessor app in 5 minutes leads to a false sense of achievement and security. (Now spend the next 6 months battling the class-library infrastructure to get the thing working how you want it). (Caution, mini-rant approaching) ....but it's not all Microsoft's or even the .NET-type programmers' fault, I've seen managers drool when presented with flashy GUI's. I've seen people promoted on the strength of a cardboard GUI with nothing behind it. (Rant ends). In my opinion (not humble, or otherwise), .NET == programming with nappies. And on a professional note, the company I contract for are moving away from Microsoft, so we're looking initially at Linux cross-platform code. Which means no .NET. Anyone know if Microsoft are now "deprecating" (love that word!) "old" COM? I'm interested purely because if we use COM under Linux, then we're flogging a compatibility dead-horse. Ho hum, back to using sockets for IPC.....

Why are you filling this discussion thread with your trolls? Take it elsewhere.

Glad you liked it, I used to watch it when I was in England. ( Will you be wanting the butcher's special then, Sir ;) )

A1> It's an fiendish plot for worldwide domination. A2> Just part of Microsoft's strategy of encouraging developer's to move to .NET ....wait a minute, isn't A2 the same as A1!!!!!!!! :eek:

Hi (excuse the interruption) How (why?? :confused: ) did you get all three OS's on the same partition! Q1> Do you have three separate WINNT system folders? Q2> Do you have a common Program Files folder. If you answer yes to both then you can probably safely remove the WINNT system folders for the relevant OS's. If not....... boot.ini should be in the root folder of your boot partition. If you can't see it turn off the option to hide system/hidden files in explorer options. Mick

OK, that's clearer. If you call into another process from another process, you have two address spaces. What this means in reality is this. You have a pointer to an area of memory (a C++ object for example). This pointer has a physical address, say 0x1000000 which is meaningful *only* in the address space it is created in. So if you have a separate process to which you pass this C++ object pointer to and try to de-reference it, then it will not point to the object you want. This is why you need the shared-memory approach. Of course, you have to come up with a way of calling a function in another process first using some form of IPC. (Into the realms of COM here). In fact, that's what COM out-of-process servers are designed for. NOTE: You can expose the C++ object as shared memory between two processes, but you still have to thread synch because two threads are (potentially) using the same memory concurrently. If you want to create a separate thread in the same process then pass a C++ object by reference (pointer) then that's the simpler solution. You still have to synch access on the data (the C++ object's methods and attributes) though. My advice, do the in-process (two threads in same address space) approach first, with thread synchronisation, then migrate the code to calling cross-process later.

Hi Gerry, I need to know a few more things to be able to help. Re: I would like to see sample code on Prasanth's solution. It's there in his post. Prasanth is spawning a process from another process. Is this what you want to do? Re: What if I need to pass an object, from 1 process to another. C++ object? COM object? OS handle object? Binary data 'object'? Other(?) Do you pass the object at from one process to the other when the second process is started? or.. Do you pass the object when the second process is already running? Re: Is my object Thread-Safe or do I need to sync data? Depends on the object (See last comment) and on what you intend to do with it. If you can describe what exactly you want to do, I will be hopefully be able to give you some better advice.

Oops, forgot to ask the obvious question (Just saw Prasanth's post :-O) Do you need to pass the data at application launch? (Prasanth's solution) or at run-time? (my suggestions)

I can think of three ways: 1) Use Shared memory 2) Passing a WM_DATA message to your rxing applications window (This also works for passing data between 16 & 32 bit apps). 3) Make the rxing exe a COM server. What's your level of expertise? Do you need more info or is this enough to get you started? "You can lead a horse to water but a pencil has to be lead"

Weird, I just logged on to the code project with the intention of starting an Xbox thread, and what do I find?:confused: Anyway, enough about strange coincidences. My $0.02 I think that the development of the Xbox could be the start of something even bigger. Like the evolving of the legacy PC architecture. Intel also want to move away from the existing PC architecture, and it would simplify OS driver development if support was dropped for legacy PCI AGP et al. (Not to mention the IRQ problem.) No more incompatible drivers? Microsoft are now looking at driving the hardware market, I see this as a logical extension of their PCxx compatibility initiatives. Even if the Xbox isn't the end-result, I think its design *will* influence the future hardware direction of the PC (Or whatever is equivalent to a PC in the future).;)

Thanks for the thanks :-O Let me know how the project turns out. :-D There are three types of people in this world, those who can do arithmetic and those who can't.

Hi, back again..... (And modified to remove scurrilous comments!) New comments in bold or italic (or both) "My point is that I most of the things MS is accused of are not in and of themselves illegal. Sure, many might be immoral, but that's not something to sue them over." I got the impression that the whole trial was a knee-jerk industry reaction, I'm sure a lot of competitors were looking for a reason to tame Microsoft. From that point of view I think the whole trial was a wasted opportunity, because the wrong issues were debated and the judge made himself look like he was just in it for his own gain. "If the court cannot say "You became a monopoly on this date", how do you draw a line and say that things you did before that date are legal, and things you did after that date are not? " Like I said, I think it was an industry reaction of too little too late. In my opinion the whole anti-trust argument was a legal mechanism for interested parties to try to stick it to MS. "Companies are allowed, by law, to say many things about their products, in the name of advertising. For instance, I can say "The #1 choice" legally, even if it's not. This is known as chest pounding, and is expected." That's something along the lines of what I meant by "spreading lies and innuendo". I think this type of practice should be subject to closer scrutiny. Not coming from or having lived in the States I can't make any valid comments, but in Europe, advertising practices like this are a little fairer. So lying in advertising is protected by the Law? But anyway, I think I've spent enough time on this, I'd rather make a post to help someone with a coding prob. than debate this any further.;) The only thing I want to add is that I think Microsoft practice a double standard as far as intellectual property is concerned. They have never been averse to ripping off other peoples product. (Stacker?) I'm sure there are many more, but I can't remember off the top of my head). It's interesting to consider that if any of technology Microsoft manufacture was subject to the GPL, then they would have been forced to withdraw the product or release it into the public-domain. Now that's got to scare Bill.:suss: Interesting commentary which I heard before, but couldn't trace the source, about the development of Altair Basic: Someone else's intellectual property was used without compensation (Dartmouth BASIC, donated to the public domain). Development was done by "borrowin

Tried to reply to this post yesterday, but something went wrong with the submission, but anyway. I was pointing out that the responses to the journalist who made the original posting made interesting reading. But it's nice to see people care enough about Microsoft to stand up for what they represent. "Sharp Business practices aren't illegal. It's only when you cross a certain, magical line that isn't clearly defined in any legal text and can only be decided by a judge, that certain practices become illegal." Perhaps a judge is necessary to ratify the exact legal and financial ramifications of such practices, but actions such as spreading lies and innuendo about competitors' products I think should be dealt with more harshly. And to be frank, I don't believe Microsoft will desist from sharp-practices after their slap on the wrist, they will simply become more circumspect about their actions. I would put more, but other people have responded to your comments with more eloquence.;P In a dog-eat-dog world, when you get to be top-dog, you're still a mutt.

OK, back again. A word of warning, I'm giving these answers on-the-fly, some info might not be 100% correct. >But wait ... what about possible handshaking between hardware and ser-port. Could this cause a deadlock ? >Maybe an app is sending midi-msg through the ser-device and the device waits for a handshake. The handshaking is set up by configuring the serial port (either via the serial port property pages or programmatically). You should 'capture' the serial port when your driver inserts itself. This won't necessarily deadlock the machine if your driver blows it's stack or something, but may require a reboot to release and reset the serial port. As far as the MIDI stuff goes, what you actually are writing is a *MIDI driver*, which uses the serial port. So your drivers should be enumerated by the system as a MIDI device, and query your hardware to enumerate all the midi devices on the serial port. The actual serial port access is the *easy* part. You should be able to drive the serial hardware from user mode, but test performance first. Besides which, if you write it correctly, you can develop the driver fully in user-mode, then try a kernel-mode implementation only if you can't get the best performance. Another point to note is that the device driver may integrate better with windows not as a pure MIDI device, but as some type of DirectMedia driver. OK, that's as much useful advice as I can give.... Abbreviations IMHO In My Humble Opinion IMO In My Opinion AFAIK As Far As I Know RTFM Read The F*****g Manual (Note, this is *not* necessarily insulting) ROFL Rolls On Floor Laughing (Also ROFLMAO, MAO - My A** Off) WTF What The F*** Look for 'MIDI' & 'serial' in the MSDN & DDK. (That's a 'RTFM' (!)) Are you in Germany? Italiano or Deutsche? (I'm in Munich);)

Hi Mario, glad you found my comments useful, let's see if I can be of any more help. Now you've established that driving the hardware via the serial port using the API calls is ok, let's look at the next problem. So I need to ask some more questions. First off, MIDI is not my forte, and I've never played around with any midi devices or applications, so bear with me. The problem is you have a piece of hardware which hangs off of the serial port. Q> Do you want to detect when the device is plugged in or removed? (This implies some way of enabling Plug-and-Play for the serial port). I think this would be nice to have, but not necessary to get the driver working. Q> Do you need a MIDI application to 'see' the hardware on the serial port as a MIDI device? (If yes, then it sounds like you want to write a 'layered' driver which sits between the MIDI device drivers and the serial port, rerouting MIDI commands to the serial port) To answer your other question, for Win2K and 98/ME (and I assume XP), the most 'compatible' drivers are WDM drivers. (By compatible, I mean write-once, run on any WDM platform... in theory). The book I mentioned yesterday (which I couldn't remember the title of) is "Writing Windows WDM Device Drivers" by Chris Cant. It's pitched at an accessible level, and contains some good information. It also explains some of the differences and similarities between 'classic' NT style drivers, Windows 95 style VxD drivers, and the new WDM stuff. It's also much more readable than any other device driver books I've read. Whether it's 100% relevant to your current problem I can't say, (I only have three device driver books, which is not a large enough sample to give a good recommendation). But IMHO it's a good place to get the basics of the differences between the various driver types you can have on Windows platforms. l8r "The project spec. said 'customer *needs* to go to the top of the mountain'....nobody stopped to ask him why"

Ahh, much clearer. First off, to read and write to the serial port under Windows 98 & 2000 is not too difficult, just use the relevant Win32 API calls. (CreateFile() with the correct parameters to open the device, then take it from there. Plenty of info on sequential and overlapped IO, etc. in the MSDN) It sounds like you actually want your driver to appear as some kind of generic midi device and internally route midi commands via the serial port? (Or am I barking up the wrong tree?) I imagine this requires a bit of registry jiggery-pokery to have your app. appear in the driver list. Not sure if this is possible with a pure user-mode driver, I'm not that au-fait with the user-mode part of WDM under Win2k/98 yet. My development advice is to get the serial port access down pat first, then migrate it to some kind of 'virtual device' driver later (No I *didn't* mean a VxD in case anyone reading this was about to flame me). As for the different modes (user mode or kernel), the difference is that kernel mode drivers can use privileged processor instructions (IO read and writes for example) and can therefore access hardware directly. User mode drivers need to go via a kernel mode (or other user-mode) driver to access hardware. There are other differences of course, but you need to read the books I mentioned in the first post for more detail. The book you mentioned, nope, sorry but I haven't heard of it. If I'm right about what I *think* your asking about (see comment above, 'barking up the wrong tree' ;) ) then the books I mentioned are not the ones you want right now. If you need info on serial communications under windows, use the MSDN. Can't remember if there's anything on the topic in Petzold(not likely) or Richter(maybe). Richter goes into overlapped and sequential IO and threading issues, but I'm not sure if he specifically looks at the serial port. Hope this helps :cool: