|
You shouldn't be using WMI for this. Instead, you should be using the Performance Counters. Check out this[^] example on MSDN. It's doing exactly what you described.
RageInTheMachine9532
"...a pungent, ghastly, stinky piece of cheese!" -- The Roaming Gnome
|
|
|
|
|
|
I didn't say you couldn't get the perf data using WMI. I said, you SHOULDN'T use WMI for it. If you want Performance Counter data, use the PerformanceCounter classes. It's what they're there for and you don't have to wrap a bunch of WMI junk to get something that's already been wrapped for you.
RageInTheMachine9532
"...a pungent, ghastly, stinky piece of cheese!" -- The Roaming Gnome
|
|
|
|
|
i wanted know how make a program residentable in memory in vb6.0
thanks,
Try to make your life a good code!
|
|
|
|
|
You're using an old DOS term. The only equivilent in Windows is a Service, which VB6 can't directly build. You have to write your application carefully so you can use another application to HOST your app as a service.
Take a look at this[^] for more information.
RageInTheMachine9532
"...a pungent, ghastly, stinky piece of cheese!" -- The Roaming Gnome
|
|
|
|
|
I am trying to get some basic Windows Services up and running, using barebones code from MSDN tutorials. I've downloaded the latest SDK, and used code straight from their site, but I'm getting an error message.
System.IO.FileLoadException: The located assembly's manifest definition with name 'interop_msxml' does not match the assembly reference.<br />
File name: "interop_msxml"
Does this mean I've got either an old dll or old code? Or am I oversimplifying?
________________________________________________________________________
Dave
Y10K bug! Let's not get caught with our pants down **AGAIN**! (DC 02002)
|
|
|
|
|
Delete the contents in your Bin folder, Recompile your application and turn on your JIT Debugger if it's not on.
Where did you get the original source, I'd like to download it.
Thanks,
progload
|
|
|
|
|
You mean the SDK itself? Here:
http://www.microsoft.com/downloads/details.aspx?familyid=EBA0128F-A770-45F1-86F3-7AB010B398A3&displaylang=en
Or you mean the code snippet? Here:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wmsrvsdk/htm/configuringbrdcstpubpt.asp
________________________________________________________________________
Dave
Y10K bug! Let's not get caught with our pants down **AGAIN**! (DC 02002)
|
|
|
|
|
Dave,
thanks for the links..
progoad
|
|
|
|
|
"Delete the contents in your Bin folder, "
Didn't have any effect.
"Recompile your application and turn on your JIT Debugger if it's not on."
OK, I did that, but all that does is put the error message in a prettier box to read. Now the error message is this:
"An unhandled exception of type 'System.IO.FileLoadException' occurred in system.windows.forms.dll
Additional information: The located assembly's manifest definition with name 'interop_msxml' does not match the assembly reference."
I have tried removing and then adding the two offending dlls (interop_msxml.dll, microsoft.windowsmediaservices.dll) into the reference, but I can't - they don't show up in the component list at all, even though I've managed to add them. (I can tell I added them because when I try to do it again, it tells me it couldn't, since there is already a reference to this component in the project.)
Oddly, the place where it's blowing up isn't near the start, it's at this line:
Playlist = BCPubPoint.SharedPlaylist
even though there's lost of references prior to this:
...<br />
Dim BCPubPoint As IWMSBroadcastPublishingPoint<br />
Dim Playlist As IWMSPlaylist<br />
...<br />
If BCPubPoint.BroadcastStatus = WMS_BROADCAST_PUBLISHING_POINT_STATUS.WMS_BROADCAST_PUBLISHING_POINT_STOPPED Then<br />
BCPubPoint.Start()<br />
Playlist = BCPubPoint.SharedPlaylist
If I comment that one line, it doesn't blow up.
________________________________________________________________________
Dave
Y10K bug! Let's not get caught with our pants down **AGAIN**! (DC 02002)
|
|
|
|
|
Dave,
Sorry, I don't have an answer yet..
Looks like it has something to do with SP1 for server 2003..
Mine is also that way (???), I haven't used the PIA since I put in SP1, I checked the GAC and It has put two different assemblies and manifests in the GAC on mine when I installed SP1, and it seems to have broken a test program I wrote last year. Give me a little time and I'll see if I can track down the problem.
If anyone else knows what's going on here, please feel free to comment on this.
progload
|
|
|
|
|
While CP was Down for the count...
I did a little more investigating and came up with this:
There are (after W2k3 SP1 Install) "Two" different versions.
-interop_msxml.dll in sdk: 2.0.0.0
-interop_msxml.dll in SP1: 9.0.3693
-microsoft.windowsmediaservices.dll in sdk: 9.0.0.3665
-microsoft.windowsmediaservices.dll in SP1: 9.0.0.3693
I referenced the ones from the original SDk (v2.0.0.0 and v9.0.3665)
and it seems to go back to working on mine here.. and my old test code is working again.
What other problems it will have.. I have not checked out as of this time.
When I reference the ones from SP1(v9.0.3693 and v9.0.0.369) I get the error you describe.
I'll go ahead and download the New SDK for SP1 and see what happens but it may take a day or two.
I hope some of this Helps..
progload
|
|
|
|
|
It's a *huge* help just knowing that it isn't me and my lack of knowledge.
So, I don't know if I have versions from before but I'll go looking.
Thanks - and keep me posted.
________________________________________________________________________
Dave
Y10K bug! Let's not get caught with our pants down **AGAIN**! (DC 02002)
|
|
|
|
|
Well, with a bit of fancy footwork, I seem to have gotten v2.0.0.0 in there and it is behaving thus far.
I can't really say how, since I don't really understand the interplay between adding a reference, including the dll in the folder and creating the runtime of the dll.
Note there is a diff in filenames between 2.0.0.0 and 9.0.0.*: interop_msxml.dll vs. interop_MSXML.dll. I don't know if that factors in or not. It did allow me to have both dlls in the folders simultaneously whikleI was busy configuring it.
________________________________________________________________________
Dave
Y10K bug! Let's not get caught with our pants down **AGAIN**! (DC 02002)
|
|
|
|
|
Have you had any luck on tracking this discrepancy down? I continue to have this problem, despite a brief period where I seem to have gotten it working.
________________________________________________________________________
Dave
Y10K bug! Let's not get caught with our pants down **AGAIN**! (DC 02002)
|
|
|
|
|
I am going through the exercises in a textbook to learn about exception handling. This is my code:
<br />
Dim n1, n2 As Integer<br />
Dim n3 As Single<br />
n1 = CInt(txtIn1.Text)<br />
n2 = CInt(txtIn2.Text)<br />
Try<br />
lblOut.Text = n1 / n2<br />
Catch ex As Exception<br />
lblWarn.Text = "Warning!"<br />
End Try<br />
1] The book says Catch e As Exception, but Visual Studio defaults to 'ex' instead of 'e'. If I deliberately put in 'e', I get a build error: "Variable 'e' hides a variable in an enclosing block." What is wrong here?
2] It seems to me that, if a zero is put into txtIn2, it should throw an error. It doesn't. It handles it gracefully, but unexpectedly, putting the text 'Infinity' into lblOut.
How am I suppsoed to learn exception handling if it won't act ... exceptional!
________________________________________________________________________
Dave
Y10K bug! Let's not get caught with our pants down **AGAIN**! (DC 02002)
|
|
|
|
|
DaveC426913 wrote:
n1 = CInt(txtIn1.Text)
n2 = CInt(txtIn2.Text)
I don't think you're supposed to use CInt, you should use Convert.ToInt32. VB.NET contains a lot of VB6 crap, because the VB community complained when Microsoft initially ( and with good reason ) removed it.
DaveC426913 wrote:
The book says Catch e As Exception, but Visual Studio defaults to 'ex' instead of 'e'. If I deliberately put in 'e', I get a build error: "Variable 'e' hides a variable in an enclosing block." What is wrong here?
1/ it doesn't matter what you call your variable
2/ you have another variable called e that's visible to this one, so you can't do this, because one overrides the other
3/ you should catch DivideByZeroException, not just Exception. This will catch ANY error, including ones you have not anticipated and/or can't recover from.
DaveC426913 wrote:
2] It seems to me that, if a zero is put into txtIn2, it should throw an error. It doesn't. It handles it gracefully, but unexpectedly, putting the text 'Infinity' into lblOut.
Good question. VB sucks. Use C#. I tried this now, and even if I set n3 to be n1/n2, it still does the same. C# throws an exception, like all real programming languages.
I find it hilarious that your book doesn't know that this doesn't throw an exception, I wonder if the author bothered to try it.
*edit* I apologise if the above seemed harsh, but I have to tell you, the whole office is laughing about this VB 'feature' right now. I'm not wanting to give you a hard time, just VB.
Christian Graus - Microsoft MVP - C++
|
|
|
|
|
Christian Graus wrote:
I don't think you're supposed to use CInt, you should use Convert.ToInt32.
Actually, you can still use CInt without any worries of it being on the chopping block in 2005. CInt is actually faster than using Convert.ToInt32 because CInt's conversion code is compiled in-line with the expression. There's no method call to setup and jump to.
His code is converting the DivideByZero exception to a string before it blows up. This results in the string "Infinity" being returned.
RageInTheMachine9532
"...a pungent, ghastly, stinky piece of cheese!" -- The Roaming Gnome
|
|
|
|
|
Isn't CInt one of the legacy methods that was going to be removed ? I wasn't sure on this.
Dave Kreskowiak wrote:
His code is converting the DivideByZero exception to a string before it blows up. This results in the string "Infinity" being returned.
Wrong. I converted into code which didn't use strings at all, and the Single variable gets the VALUE of positive Infinity. That's where the string value comes from, the Single, which does not blow up. Then I changed the code to set to an int, and it DOES blow up then, but it doesn't throw a DivideByZero exception, it throws an OverflowException. C# will blow up on a divide by zero, no matter what type it's being set to, and it throws the right exception.
Do you have an explanation for this that doesn't involve the VB.NET design team spending most of their time drunk ? Because we spent a Friday laughing about it here ( where we never use VB.NET ).
Christian Graus - Microsoft MVP - C++
|
|
|
|
|
Christian Graus wrote:
Wrong. I converted into code which didn't use strings at all, and the Single variable gets the VALUE of positive Infinity. That's where the string value comes from, the Single, which does not blow up.
Sorry. I suffered a momentary rectal/cranial inversion. 
It would be interesting to see what IL is generated for the same code.
I'll try and take a look at that when I get to work.
RageInTheMachine9532
"...a pungent, ghastly, stinky piece of cheese!" -- The Roaming Gnome
|
|
|
|
|
Dave Kreskowiak wrote:
I suffered a momentary rectal/cranial inversion
*grin* I'd certainly forgive you for assuming this would not be the case, it's pretty screwed up.
Dave Kreskowiak wrote:
It would be interesting to see what IL is generated for the same code.
I'll try and take a look at that when I get to work.
I'd be really interested to hear your thoughts. Overall, I thought that VB.NET and C# did roughly the same thing, and this sort of difference is frankly astounding to me.
Christian Graus - Microsoft MVP - C++
|
|
|
|
|
After doing a little code and IL research and going back to the VB.NET docs on mathematical operators, all has become crystal clear. There are TWO division operators in VB.NET. Click here[^] for the docs, or just read on...
The normal one, that we're all used to using in any language, is "/". Well, in VB.NET, this operator is only used to divide two floating point numbers. The operator is defined for both the Single and Double types and also the Decimal type.
The Single and Double types are evaluated using standard IEEE 754 rules. Nothing new here, it's what we've been using for decades in C/C++ on floating point values and where our "interpretation" problem comes in while evaluating the original posters n1/n2 expression.
The Decimal type is a little different. If the right-hand operand is 0, the a System.DivideByZeroException is thrown. If the resulting value is too large to hold in the Decimal type a System.Overflow exception is thrown. If the resulting value is too small, then the Decimal type result will be 0.
The second division operator in VB.NET is "\" and is reserved for integer division using the VB.NET Byte, Short, Integer, and Long types. This is the division that the equivilent C# code is doing when comparing VISUALLY identical VB.NET and C# code using integer operands!
Now, according to MSDN:
"According to normal operator resolution rules, regular division purely between operands of types such as Byte, Short, Integer, and Long would cause both operands to be converted to type Decimal. However, when doing operator resolution on the division operator when neither type is Decimal, Double is considered narrower than Decimal. This convention is followed because Double division is more efficient than Decimal division."
Keeping that statement in mind, here's the proof of what's going on with the OP's code:
This is the test function code for VB.NET:
Dim n1, n2 As Integer
n1 = Convert.ToInt32("32")
n2 = Convert.ToInt32("0")
Console.WriteLine(n1 / n2)
The output is the string "Infinity". Something C# and C/C++ coders wouldn't expect to see.
The test function in C# is:
int n1;
int n2;
n1 = Convert.ToInt32(@"32");
n2 = Convert.ToInt32(@"0");
Console.WriteLine(n1 / n2);
This throws a DivideByZeroException on the Console.WriteLine call. No surprise there.
The difference (and proof) is in the IL.
First, both functions call the same conversion method to convert a string to an IL int32 type. The IL code appears to be the same between the two. Both generate:
.maxstack 2
.locals init ([0] int32 n1,
[1] int32 n2)
IL_0000: nop
IL_0001: ldstr "32"
IL_0006: call int32 [mscorlib]System.Convert::ToInt32(string)
IL_000b: stloc.0
IL_000c: ldstr "0"
IL_0011: call int32 [mscorlib]System.Convert::ToInt32(string)
IL_0016: stloc.1
Nothing surprising here. Both functions do exactly the same thing with exactly the same data types.
Both calls to convert are followed up by storing the resulting int32's into their appropriate storage locations.
The problem is in the division expression. The C# IL is:
IL_0017: ldloc.0
IL_0018: ldloc.1
IL_0019: div
IL_001a: call void [mscorlib]System.Console::WriteLine(int32)
IL_001f: nop
IL_0020: ret
Simple enough. Load the int32 in location 0 onto the eval stack, then load the int32 in location 1 onto the eval stack. Do a divide operation on those two integers (int32 / int32). Call Console.WriteLine with the result.
The VB.NET IL is VERY different using the exact same character for the operator, but it has a different function. Using "/", the expression isn't evaluated as an int32 / int32. Both operands are first converted to IL float64's (or System.Double type) before the division operation. We all know the results of storing and operating on floating-point numbers in IEEE 754 format... Anyway, this is the VB.NET IL:
IL_0017: ldloc.0
IL_0018: conv.r8 <- Converts the value at the top of the eval stack to float64!!
IL_0019: ldloc.1
IL_001a: conv.r8 <- Converts the value at the top of the eval stack to float64!!
IL_001b: div <- IEEE 754 rules are different than integer division rules!
IL_001c: call void [mscorlib]System.Console::WriteLine(float64)
IL_0021: nop
IL_0022: nop
IL_0023: ret
Now, change the VB.NET code to:
Dim n1, n2 As Integer
n1 = Convert.ToInt32("32")
n2 = Convert.ToInt32("0")
Console.WriteLine(n1 \ n2)
Of course, the resulting division IL code now falls in line with the expected C# IL code:
IL_0017: ldloc.0
IL_0018: ldloc.1
IL_0019: div
IL_001a: call void [mscorlib]System.Console::WriteLine(int32)
IL_001f: nop
IL_0020: ret
If the OP changes the operator in his expression from "/" to "\", it'll do exactly the same thing as the equivilent c# code.
BTW: This testing was done on C# 2005 and VB.NET 2005, Beta 2.
This has been a public service announcement. We now return you to your regularly scheduled program...
RageInTheMachine9532
"...a pungent, ghastly, stinky piece of cheese!" -- The Roaming Gnome
|
|
|
|
|
Thanks - I had pieced part of this together with some help already ( the two operators thing ), but this makes everything quite clear. The core issue then is the convert to a float64. I wonder if these conversions behind the scenes are a reason for the argument that VB.NET is slower than C# ?
Does this mean that C# can't divide using IEEE 754 rules ? Or is it just that VB.NET, being loosely typed, does conversions behind the scenes that C# does not. Certainly I could see where the overflow exception came from, that all makes sense now.
Christian Graus - Microsoft MVP - C++
|
|
|
|
|
Christian Graus wrote:
The core issue then is the convert to a float64. I wonder if these conversions behind the scenes are a reason for the argument that VB.NET is slower than C# ?
It'll definitely contribute to the speed difference because of the conversion process and the 64-bit floating division. But I think the problem lies in the fact that the people who want to bash VB.NET so bad just write some ad-hoc test code for both languages, like in my post, don't realize that they're not comparing apples to apples. When the difference comes up, wow!, they just jump all over the language.
Christian Graus wrote:
Does this mean that C# can't divide using IEEE 754 rules ? Or is it just that VB.NET, being loosely typed, does conversions behind the scenes that C# does not.
No. C#, being based on the same Framework, using the same types and generating the same IL, uses the exact same math rules VB.NET does. C# just has a syntax advantage in the compiler where is will recognize the division situation, since it only has a single division operator, and generate the correct code automatically, (for example when dividing an int32 by an int32, assume the result required is an int32 and generate code for integer division), where VB.NET puts more of that decision process on the coder. The coder is responsible for explicitly telling VB.NET which type of division to use, integer (\) or floating-point (/).
I guess you could make a case for that being a simpler advantage for VB.NET, I don't know. In C#, if you wanted to force floating-point division on two int32's, you'd have to cast the operands to some floating-point type in the expression. IMHO, I'd say it might be slightly simpler to control in VB.NET, but more readable and comprehendable in C#.
RageInTheMachine9532
"...a pungent, ghastly, stinky piece of cheese!" -- The Roaming Gnome
|
|
|
|
|
Dave Kreskowiak wrote:
IMHO, I'd say it might be slightly simpler to control in VB.NET, but more readable and comprehendable in C#.
Fair enough - thanks for taking the time to look into this, I've found it quite fascinating.
Christian Graus - Microsoft MVP - C++
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
