Derek Stone

Do you need a driver or something to detect movements and clicks of the wheel?

It is quite an undertaking, and it's about half done. Security, stability and speed have all been matched and exceeded due to the architecture of the project, and the feature set will improve as time passes. VBulletin is a great product for systems limited to PHP, but it simply can't match the speed and scalability of ASP.NET. The conversion is being made due to too much stress on the current database server, and this project has already proven, in my tests, to be fair more efficient than the current implementation. If anyone is seriously interested in helping out with this project please contact me directly. We still have quite a bit of work left to be done.

Have the policies on the machines affected been modified from the defaults? If they haven't there is absolutely no reason as to why those executables should be throwing any security exceptions. Runtime Security Policy | Machine | Code Groups | All_Code | My_Computer_Zone Make sure that's set to the "Full Trust" permission set.

Declare Function auxSetVolume Lib "winmm.dll" Alias "auxSetVolume" ( _ ByVal uDeviceID As Integer, _ ByVal dwVolume As Integer) As Integer

http://www.xtremedotnettalk.com/showthread.php?s=&threadid=77175

Are you running the application from a network drive?

You'll have to use the Win32 API from .NET to interact with windows bound to other processes. VB.NET: Platform Invoke As for SendKeys you just simply shouldn't use it. Call the SendMessage API function with WM_SETTEXT as a parameter instead.

Look under the term "tool band". http://msdn.microsoft.com/workshop/browser/ext/extensions.asp

Your NTFS file/directory permissions are configured incorrectly. Consult Checklist: Securing ASP.NET and the .NET SDK under [mshelp=ms-help://MS.NETFrameworkSDKv1.1/vsdebug/html/vxtskErrorJITDebuggingFailedWithFollowingErrorAccessIsDenied.htm]JIT Debugging[/mshelp].

The only place cookies are stored is on the client. Sessions also require cookies, unless you set the application's configuration file to act otherwise (append the session ID to the URL).

A simple linear guestbook-type bulletin board would not be that hard to create, granted you know basic SQL syntax.

Yes to both of your questions. The coding is the same and you can pass parameters and return values.

If the sessions ends the user should automatically be signed out. In a Web-based environment there is no absolute way of determining when the session has ended. You need to re-evaluate how your authentication scheme works, since it appears to be somewhat flawed if you need to explicitly log someone out. The absence of a cookie (or a session, little difference) should be enough to deny access.

I used to run Visual Studio .NET on a PII 400MHz with 256MB of RAM. It was just as responsive as it is on my current computer, both the IDE and the framework.

I think I understand what your attempting to do now. Executable --> Unmanaged C++ library --> Managed C# library You've got two choices as far as I see it: 1) As you mentioned, instantiate a .NET DLL that's been exposed through COM 2) Load the CLR into the unmanaged C++ library and invoke managed methods through the provided interface Both are ugly as far as I'm concerned, but it's either ugly or code everything in C++.

Yes. Compile the DLL in Visual Basic 6 and add it as a COM reference in your .NET project.

Very true, but what defines a managed application?

There are two types of DLLs one can interoperate with from managed code: standard libraries and COM libraries. Standard libraries expose methods and methods only, meaning they have no concept of classes, nothing but a figment of our imagination back in the days of C. You'd use platform invoke (of which DllImport is a part of) to call these methods. COM libraries on the other hand support full OOP and contain the classes we now all know and love. To interop with these libraries from .NET we create a COM-callable Wrapper (CCW). Now the question is this: what is this legacy code you're talking about? Is it a static library (*.lib) or is it in an executable format (*.dll)? If it's the former your best bet would be to generate a COM wrapper which exposes the necessary method interfaces and types to the outside (non-C++) world. If it's the latter you'll need to determine if the DLL is standard or if it is exposed via COM, and then make any decisions based off of that. There's a good chance you've answered these already, and I'm just blind, but bear with me.

This can be done very easily using the [msdn=System.Net.WebRequest]System.Net.WebRequest[/msdn] class.

Both of those attributes only apply when the application is interoperating with a COM component. They exist to allow communication between single-threaded and multithreaded architectures. An unusually understandable definition and explanation of apartments can be found in the Platform SDK. http://msdn.microsoft.com/library/en-us/com/htm/aptnthrd_8po3.asp If you have any questions after reading that I should be of some assistance, since I ran across these types of questions back in Visual Basic 6 when I was looking into threading. Many answers you'll find will be vague and at points utterly useless, but alas, that is the nature of the beast known as COM.

Dim i As Int64 = DateTime.Now.Ticks Dim interval As Int32 = 10000 'Milliseconds While ((DateTime.Now.Ticks - i) <= interval) 'Loop End While

Given a half hour anyone with a decent understanding of IL could "hex out" your protection scheme.

Nearly anything short of operating systems and device drivers.

Each client has to have Internet Explorer configured to allow .NET applications to run. Under .NET 1.0 IE is configured by default to allow .NET applications from the Intranet zone to run, while .NET 1.1 allows for execution from either the Intranet zone or the Internet zone. With both, there will of course be certain code execution policies in place to prevent malicious code from executing. Given this information what you need to do is instruct your clients to enable execution from withing IE, or have them download a simple policy setup application which will make those changes for them. All in all the smart client idea is excellent, however it wasn't carefully executed by Microsoft upon rollout. Granted IE hasn't been updated for a few years now, so we know who to blame.

C# is, for all intents and purposes, a cleaner version of C++, one which I enjoy far better than the sometimes inane C++ ways. One can be much more productive in C# due to its cleaner syntax and the .NET base class libraries, which extend far beyond the MFC available in Visual C++. Without knowing the software you intend to develop it's hard to give you an entirely educated answer, but I can say with comfort that C# is likely to be the more intelligent choice. Also take note that any C++ code developed in Visual Studio .NET can be compiled, without changes, as either unmanaged (native) executables and libraries, or managed .NET assemblies. This is a huge selling point for developers switching from Visual Studio 6 to Visual Studio .NET.