Teledyne LeCroy, but where should this be?

[*3d0g]

Alice in Wonderland:

https://techcommunity.microsoft.com/t5/windows-it-pro-blog/dcom-authentication-hardening-what-you-ne...

[rolfk]

COM is a technology that is pretty old. It is one of the basic building blocks of ActiveX and many other Microsoft technologies. It was based on what Microsoft initially called OLE (Object Linking and Embedding) and as such exists since Windows 3.x days. COM was a standardization of OLE in a much more strict and formal way and supported distributed execution (the D in DCOM) through RPC over various networking layers including pipes and TCP. The Distributed part of DCOM was always a bit complicated. It's configuration was tricky and its security model was based on the promise that everything was working in a private network with no hostile attackers being able to penetrate into that network. The security model was mostly dealing with authenticating to ensure that a particular user had the rights to access and execute a service, not that that user might have malicious intend and try to hack the entire protocol stack. With internet gaining more and more traction and networks getting exposed directly to the big scary wild west of the internet more and more, the entire DCOM infrastructure soon proofed to be a major liability, and the complexity and closed source nature of DCOM, that relied mainly on security through obscurity, simply became to complicated to try to secure, without a complete redesign that would surely break any form of backwards compatibility. COM, and also DCOM, for sure are older than what is claimed in the article you linked too. In 2006 Microsoft already had been moving towards a new technology called .Net that promised to have better security standards than what DCOM ever could achieve. And while some parts of .Net initially relied heavily on COM (but barely on DCOM) under the hood, to access existing Windows services, that eventually got replaced piece by piece through other technologies accessing the Windows kernel more directly, respectively a complete redesign of the Windows kernel as a .Net based system for the Windows RT (Runtime, not Realtime) platform, which is basically the platform Microsoft intended to use for anything non-x86 desktop related, including Windows Phone, but Windows Phone got killed before Windows RT really was ready to be used for it.

Some of the Surface computers use the Windows RT system. It's basically a Windows system that has no Win32 API kernel underneath anymore but the entire platform is .Net based and only .Net applications can run on it, and without special hacks only applications that have to be downloaded from the Microsoft marketplace. LabVIEW in its current form never will be able to run on such a system, not even LabVIEW NXG could have, since it was not a completely .Net based application but a hybrid of pre-compiled binary modules with .Net based user interface.

And while Microsoft nowadays rather wishes they could make (D)COM disappear with a magic incantation of some spell, there are many parts in Windows that actually are entirely built on COM (and to a lesser degree also DCOM). The entire Windows Explorer with its Windows Shell interface is still completely COM based. Also the Service Manager is using COM for all its work and if it approaches remote computers this is actually done through DCOM. And the statement that DCOM was only released in 2006 as in your article you link to is claimed is not really true. It existed long before and for a large part was Microsofts attempt to monopolize Windows technologies, since COM implementation for non-Windows systems never reached any majority due to Microsofts very strict closed source policies for it.

So yes, Microsoft would love if they could make DCOM disappear and they are actively working on that, but as long as there is Windows desktop rather than Windows RT running on computers, this is an idle dream, since quite a lot of its technologies are built around COM (and partly DCOM) as base technology. Only the Windows kernel itself is not really COM based.

[Jay14159265]

---

@*3d0g wrote:

That DCOM going away part, does anyone here have anything on that?  I'm actually questioning it. ...rather it'll be mandatory updated out of use by Microsoft.

---

I have some thoughts on that. 

1) You should never update the windows OS running on a scope, especially if it is an older one. With the one caveat being that it is an update that is being pushed out by the scopes manufacture. Doing this only breaks things, it might not break the scope itself but as you have noticed Lecroy and Microsoft priorities don't always align (again especially for older scopes). 

2) If you stick with the original OS, you don't have to worry about Microsoft or Lecroy making things obsolete. You have the tool set that exists on the scope and that will never change, unless you update the OS. 

4) There is a way to automate your scope but it is probably not going to the the way you want to do it, it is going to be the way you have to do it based on the tools available. If you want to hack into the USB DCOM communication model, do it! But don't expect a tutorial or Lecroy manual that is going to give you a step by step for how to do that. Can you do this with LabVIEW? Absolutely if you choose to. I would imagine the reason you are not finding any posts about this kind of thing is because nobody chooses to hack DCOM to communicate with a Lecroy oscilloscope for a hobby. If anyone has ever done that, it was wile working for a business that hired them to do it. So they are not going to be posting the code here. 

5) If it is a newer scope Lecroy support can show you how to automat it, contact their solution engineering department. 

6) Maybe try the Lecroy forums, you will find people with more experience using Lecroy/MAUI over there. 

[*3d0g]

I think I have found something:

There's apparently a VBS command that is useful for working with MAUI Browser objects.  I can't say it is the solution yet, but it seems hopeful.  Now hopefully someone out there can confirm yea or nay.

[Jay14159265]

---

@*3d0g wrote:

I think I have found something:

There's apparently a VBS command that is useful for working with MAUI Browser objects.  I can't say it is the solution yet, but it seems hopeful.  Now hopefully someone out there can confirm yea or nay.

---

Looks like you struck gold there. Why not give it a try. 

[*3d0g]

---

@Jay14159265 wrote:

---

@*3d0g wrote:

I think I have found something:

There's apparently a VBS command that is useful for working with MAUI Browser objects.  I can't say it is the solution yet, but it seems hopeful.  Now hopefully someone out there can confirm yea or nay.

---

Looks like you struck gold there. Why not give it a try. 

---

There's an itsy-bitsy teenie-weenie small detail you missed.  This is about future use and determining the correct scope to invest my time in.  I'm not going to choose (and pay for) a scope that doesn't meet my specifications.  A crucial specification is I must be able to do automatically what I can do manually; otherwise, I'm throwing away money on features I cannot use or are too cumbersome to invest time in. Time is money. I'm not going fight to use the scope -- I am not a beta tester. I don't want to pull out every magic trick I can think of and reverse engineer Windows just to use a scope the way I need and want to use it. I don't have time for that. But I also don't want to limit myself to what everyone else uses, if I can see there isn't enough firepower under the hood. Make sense?      

[Jay14159265]

---

@*3d0g wrote:

---

@Jay14159265 wrote:

---

@*3d0g wrote:

I think I have found something:

There's apparently a VBS command that is useful for working with MAUI Browser objects.  I can't say it is the solution yet, but it seems hopeful.  Now hopefully someone out there can confirm yea or nay.

---

Looks like you struck gold there. Why not give it a try. 

---

There's an itsy-bitsy teenie-weenie small detail you missed.  This is about future use and determining the correct scope to invest my time in.  I'm not going to choose (and pay for) a scope that doesn't meet my specifications.  A crucial specification is I must be able to do automatically what I can do manually; otherwise, I'm throwing away money on features I cannot use or are too cumbersome to invest time in. Time is money. I'm not going fight to use the scope -- I am not a beta tester. I don't want to pull out every magic trick I can think of and reverse engineer Windows just to use a scope the way I need and want to use it. I don't have time for that. But I also don't want to limit myself to what everyone else uses, if I can see there isn't enough firepower under the hood. Make sense?      

---

lol well you had me going, I thought you had an actual engineering/hardware question to solve. Since this has turned into an opinion piece, here is some biased advice for a hypothetical future: don't use high end Lecroy scopes, they are for advanced users that have an objective test goal and you will be frustrated by them for general purpose applications. Don't use LabVIEW for new projects it is a dying language.