Keep in mind that all obfuscation is still only obfuscation. If a
customer can run the code, they can (eventually) reverse engineer it.
If you encrypt an assembly, then the customer's computer cannot decrypt
or run it. So, of course, the obfuscator includes a stub that both
decrypts and runs the
The main reason that methods are not virtual by default in C# is because
virtual methods allow derived classes to alter the contract between a base
class and the user of a class, without the base class having any control
over how this is done, or even knowledge that this is being done. In other
I believe it gets down to one message pump handling
UI messages--since each message pump needs to be on
it's on thread there can be only one UI thread.
Win32, and WinForms, both *definitely* support having more than 1 UI thread
per process. You need to do the right thing in WinForms, which
No way no how. XP is a client OS. The documentation for IIS on XP
clearly states that there is a connection limitation. This is by design.
By the time you are doing stress testing, you should have access to a
server. Even if you are still doing development in your office, you need to
acquire
Use the CLR memory profiler. It does a good job of showing you what's
chewing up memory. That is, if it is instances of managed classes. If
you're leaking unmanaged memory, it's more difficult to diagnose.
-- arlie
-Original Message-
From: Unmoderated discussion of advanced .NET
Such optimizations could be done only if the method never modifies the
structure. Detecting this is easier with MSIL (though not trivial) than
with previous compilers.
-- arlie
-Original Message-
From: Unmoderated discussion of advanced .NET topics.
[mailto:[EMAIL PROTECTED] On Behalf
That isn't my decision to make. Managed DirectX uses value types for Matrix
and several other types. Overall, I agree with the decision.
I'm certainly not going to waste my time rolling another managed interop
layer for DirectX.
-- arlie
-Original Message-
From: Unmoderated
also decides to inline the function
in question -- wouldn't even need to pass a pointer, on x86 -- just emit
opcodes which read the fields from somewhere above the ebp, instead of below
it.)
Cheers,
-Shawn
http://www.windojitsu.com/
-Original Message-
From: Arlie Davis [mailto:[EMAIL
That's all nice and applicable to 3D programming, but it's not really
relevant. No matter how fancy your shaders are, and how powerful your GPU
is -- you will still need to manipulate matrices in your app.
Doing 3D in a managed language should not impose any undue / silly
penalties, especially
It's an empty structure because it is a stub emitted by the managed C++
compiler. In other words, the Managed DirectX libraries are written in
managed C++. This compiler has to emit *something* in the MSIL metadata
that describes the types that the MDX libraries manipulate. _D3DMATRIX is
John Elliot writes:
I guess I meant 'strange' as in 'closed source, poorly
documented, I didn't write it, etc.' (don't know much
about DirectX doco, so that's not a sledge as such).
The DirectX docs are actually fairly decent.
Say for example I'm targeting the managed DirectX API, and my
Almost, but not quite. Instances of a value type can be hosted within a
reference type, which is always allocated in the managed heap. Two threads
can then access the same instance of a value type at the same time.
However, nothing horrible can happen.
-- arlie
-Original Message-
I have a few questions for the advanced CLR people here. I haven't been
able to find any satisfactory answers elsewhere.
Consider value types / structures in CLR, and passing them as arguments to
methods. Does the MS CLR *always* copy the entire structure onto the stack?
Or does it ever simply
Well, I understand all about boxing, and I appreciate the response. But
boxing has nothing at all to do with my question.
My question is -- what, *exactly*, does the JIT compiler do when it compiles
methods that take large structures as parameters? Is there a threshold
beyond which the JIT
You definitely don't want to do it this way. This is fragile, and not even
guaranteed to find all serial ports.
Use the documented PNP APIs to discover and enumerate devices of specific
device classes. For starters, look at SetupDiEnumDeviceInterfaces in Win32
SDK.
There may be easier ways to
Angel, Philip,
ASP .Net requests can be handled either synchronously or asynchronously. If
you are handling requests via instances of the Page class, then your
requests are processed synchronously.
For the duration of a synchronous call, the entire request is handled on one
thread. ASP .Net
There are so many different ways to do this, and many of them seem
preferable to (ab)using the remoting infrastructure. Can you describe what
you are trying to accomplish, and why you believe it requires using the call
context?
-- arlie
-Original Message-
From: Moderated discussion of
Enums are not boxed directly to their base (integer) type. Casting an
instance of an enum to object boxes the enum instance. Try this some time:
Console.Write (((object) TestEnum1.Value).GetType().FullName);
-- arlie
-Original Message-
From: Moderated discussion of advanced .NET
I'm sorry, but a public internally implementable interface just sounds
like a nightmare.
Keep it simple. Interfaces are interfaces.
I think too many people focus on contorting object-oriented programming
languages into things that they are not. They are not UML, they are not
rights management
Daniel is completely correct in his description of enums. One additional
note -- if you do wish to validate enum values, validate them only when it
makes sense to do so. In other words, validate them only when they are
generated through some means other than identifying a member of the enum
Actually, although it STILL may not be a good idea, it IS safe in the
current implementation of the CLR.
The CLR does use singly-linked lists for the default implementation of an
event, i.e. public event EventHandler Foo;. However! The list is NOT
managed destructively. The default
Of course it fails. Why would you ever expect otherwise?
-- arlie
-Original Message-
From: Moderated discussion of advanced .NET topics.
[mailto:[EMAIL PROTECTED] On Behalf Of John Elliot
Sent: Friday, April 09, 2004 6:57 PM
To: [EMAIL PROTECTED]
Subject: Re: [ADVANCED-DOTNET]
Throwing exceptions in a constructor is perfectly fine in .Net. And in many
circumstances, it is the Right Thing.
If a constructor cannot build a valid instance of a class, then it should
throw an exception -- just like any other method.
One key difference between virtual methods in .Net and in
Agreed, it is a problem.
Transparent persistence never is. Transparent remoting -- also never is.
Frameworks that make message passing easy (and which allow you to easily map
message attributes to object instances or attributes) are, in general,
better. Even Microsoft is moving in that
This is more of a Win32 problem than a CLR problem. It sounds like you
are working on a service (with no user in front of it), rather than a
user app. In that case, you'll need to dig into Win32 exception and
error handling.
When a process raises an unhandled SEH exception, NT goes through all
No. Definitely not. Allocate buffers of an appropriate size before
calling ReceiveFrom or BeginReceiveFrom. Appropriate depends on your
application protocol.
-- arlie
-Original Message-
From: Moderated discussion of advanced .NET topics.
[mailto:[EMAIL PROTECTED] On Behalf Of Alex
I think that's a very fair criticism.
Partly, I think this is due to a sense of decompression after the
strict interface-based world of COM. COM interfaces were a good idea.
But COM forced everything through interfaces, since it had no real
concept of classes beyond class factories and a set of
Do NOT do this. Direct modification of the SCM registry keys is a very,
very bad idea, because it gets the registry out of sync with the SCM
itself. This has nothing to do with managed vs. unmanaged code. This
is simply the rules for using the SCM.
The best way (and it's fairly easy) is to
NEVER throw an exception. Or are
you proposing a special exception handler for unhandled exceptions?
THAT is far more offensive than any new keyword! :p
-jade
-Original Message-
From: Moderated discussion of advanced .NET topics.
[mailto:[EMAIL PROTECTED] Behalf Of Arlie Davis
Sent
Ummm, no. Methods are things that can do things. Being the top-level
method frame in a stack is just one thing you can do with a thread.
Methods should NOT be decorated with threadentry or other such
attributes.
Java has things like this, with declared exceptions that are thrown from
a thread.
1) Make sure you handle the calling convention correctly. As far as I
know, .Net only supports using the __stdcall calling convention. So
make sure that LPFN_CALLBACK is declared using __stdcall. Otherwise, if
your C++ code is compiled with a different default calling convention,
then when the
No. This is a design constraint of the NT kernel. Each thread has a
block of wait handle pointers in its KTHREAD structure, and that block
has a finite length.
The reason that it is relatively small, is that WaitForMultipleObjects
becomes more expensive when you have more handles involved.
You're mostly smoking crack. The JIT compiler knows how to inline
trivial get/set methods.
However, there's nothing wrong with this approach. In the future,
optimizers may be able to make better use of readonly hints, to reduce
pointer dereferencing, etc. But for now, yeah, there is no real
Provide performance data that backs this up, before saying there can be
quite a performance penalty.
Speculation is not data. Debug builds are not release builds.
-- arlie
-Original Message-
From: Moderated discussion of advanced .NET topics.
[mailto:[EMAIL PROTECTED] On Behalf Of Urs
#1 - Why are you trying to do this? This doesn't look like it performs
anything useful.
#2 - It appears that Microsoft's implementation is more accepting than
the specifications for Monitor.Exit. The docs are pretty clear.
-- arlie
-Original Message-
From: Moderated discussion of
In XP, disks can still be optimized for fast removal. In Device
Manager, open the property page for the storage device. There should be
a Policies tab, which has options for Optimize for quick removal vs.
Optimize for performance. On fixed disks, there are also options for
controlling write
You need more than just no caching. You need to dismount the volume,
so that the NT device driver reloads ALL state relevant to the disk.
See FSCTL_DISMOUNT_VOLUME. This is also provided via fsutil volume
dismount X:.
I don't see how this is relevant to advanced .Net topics, though.
-- arlie
Use async delegates. Declare a delegate that matches
SqlCommand.ExecuteNonQuery, create an instance of the delegate, and call
BeginInvoke on it. Provide a completion delegate. In your completion
delegate, call the delegate's EndInvoke method. Badda-bing.
-- arlie
-Original Message-
38 matches
Mail list logo
