This is the extent? COM is by no means an easy subject and Windows shell programming gets even harder (since it uses COM and adds certain complexities). You really should spend some time learning the basics. Learning things as you go is always good and you should never stop, but you have to have experience upon which to build.
Right, I have found the INCLUDE setup in my Enviroment variables of System Properties.
I have added the following entries to my INCLUDE section in the System Variables:
"F:\MSDN\SDK\v1.1\include\; F:\MSDN\Vc7\include; F:\MSDN\Vc7\PlatformSDK\Include"
Now, it appears that MSDN is NOT my VS directory, and i'm not sure if this is correct, but it contains all the include information of the PlatformSDK.
Now, i am not sure if this is actualy working, as i still gain no joy with the objidl.idl, which is in the directory "F:\MSDN\Vc7\PlatformSDK\Include".
Not sure what's wrong there.
I know Heath. I am going through the COM tutorials at the moment. I'm more than happy to take a step away from where I am in order to learn background knowledge, and since i've hit this whole DragDrop thing, i've learned a reasonable amout about C and COM from reading articles and experimenting with sample code.
It's actualy quite fun
I will continue on with these tutorials, but I think my next step would be to get my tools working. Midl and TblImp.
Never mind, i had a problem with not running vcv*something*.bat. It appears to be all working now.
Although, midl does not appear to be generating the objidl.tlb file I asked it to, despite running without errors.
Don't include spaces between delimited directories in your INCLUDE env. var. (or PATH, LIB, or any other delimited path env. vars. like that). Also keep in mind that you can use env. vars. even in those env. vars. by defining things like PSDK=F:\MSDN\Vc7\PlatformSDK as another env. var., then using INCLUDE=%PSDK%\Include.
Also, you should download the newest PSDK from MSDN. If you're using the one in your VS.NET directory, you're using an OLD one. Also, don't include directories in your env. var. in quotes. That is one thing that the OS will handle correctly when using the UI. When doing this in a command line, you would have to type it like so:
set INCLUDE=C:\SomeDir;C:\SomeDir\Some Other Dir
Make sure there's no space around the equals (=) sign and don't use quoes there, either. Also note that typing this in the command prompt only makes the INCLUDE env. var. durable for THAT particular command prompt instance. You can also append directories like so:
set INCLUDE=%INCLUDE%;C:\SomeDir;C:\SomeDir\Some Other Dir
Again, if you change the env. vars. through the Advanced tab in the system properties, you must restart any program - including the command prompt - in which you need these changes reflected (for instance, an open Internet Explorer browser window won't benefit from this change, so you don't have to restart it).
Note also that VS.NET maintains it's own list, though there is ways to make it use the system and user environment variables instead. See the Options for details and just try it out.
You're not supposed to compile the whole thing to a typelib, only forward-define the interfaces in your own IDL file and then compile that to a typelib. See the midl.exe documentation for more command-line options. Each IDL file doesn't have a typelib because many are typically meant to be included in other IDL files while being defined in a library elsewhere - this isn't your concern. Do what the linked article I gave you mentions and generate a typelib including the interfaces, structs, and enums you need ONLY. Anymore - unless you're planning on interop'ing the whole COM for a huge-ars library - is just overkill and bloat.
Nick Parker wrote: ...but I haven't gotten into that much yet.
I'd say! The Java class library has all the basic stuff, while Swing (added with Java 1.1 I believe) offers a stunning GUI class library over the prevoius AWT packages. And just like .NET, there are a ton of libraries out there (both by Sun and by third parties) to extend the basic functionality below your application, things for encryption, web services, RMI (like .NET Remoting), remoting bridges, and much more.
This doesn't mean I like it, but it serves a purpose and deserves a little respect, especially since it was the first real framework before .NET.
I'd spent about 10 minutes looking at the book when I made that comment, obviously my statement does exactly hold a lot of weight. I'm actually glad to hear what you just said; it will keep my hopes up that I will find another language I might enjoy to work with.
.NET code doesn't technically, either. It uses a bit in the executable's PE/COFF header that the app loader checks (or any other various hosts, like mscoree.dll or Internet Explorer) that sets up the host runtime and loads the application. With Java, it is the java executable that does this. The only difference is that in Windows, the executable is still loaded by the app loader than makes this check. On *nix with Mono, for example, you have to run .NET applications just like java: mono MyApp.exe
MSWord can load ActiveX and host ActiveX's toolbars, status bar and so on. Could any one tell me how can I host that ActiveX and create ActiveX in .NET ? And then load my controls as "Objects" in Word ?
Read Nick Parker's article, Creating a CCW...[^]. You should also read the System.Runtime.InteropServices documentation so you understand what's going on. Knowledge of COM is also helpful, such as understand the difference between IUnknown and IDispatch (for automation), knowing which IPersist* interfaces that Word supports (it is a typical ActiveX container), knowing what ActiveX containers are, and the like. You should also NEVER use auto-generated class interfaces (as I asked Nick to add to his article) and NEVER change your class interface after releasing your component (instead, create a new interface by appending 2, 3, etc. for each version) that derives from the first and adds methods with new DispIdAttributes for automation objects).
As far as OLE is concerned (for hosting toolbars, merging menus, hosting status bars, etc.), you'd really be best writing your component(s) in C++ as opposed to some .NET language like C# because you'll have to define LOTS of COM interfaces with the appropriate GuidAttributes, DispIdAttributes, InterfaceTypeAttributes, and so on. System.Runtime.InteropServices provides a few managed definitions (the interfaces that start with UCOM* like UCOMIBindCtx).
To hide properties you can use attribute [Browsable(false)]. I am not sure if is possible to change this value in runtime. I think you cannot.
Or you can implement TypeConverter for your class using attribute TypeConverterAttribute and than override GetProperties and GetPropertiesSupported method. By this way you can manage properties which will be "visible" in PropertyBrowser.
Wizard_01 wrote: To hide properties you can use attribute [Browsable(false)]. I am not sure if is possible to change this value in runtime. I think you cannot.
You can by implementing your own PropertyDescriptor or using an ICusotmTypeDescriptor on your component. Using this approach or adding PropertyDescriptors using your designer is more favorable than a TypeConverter. While TypeConverters can do that, they are typically not used for this purpose.
DECLARE @AuthUserId nvarchar (16)
SET @AuthUserId = (SELECT UserId FROM Users WHERE (UserID = @UserID AND Password = @Password))
-- IF ABOVE SELECT RETURN ONLY ONE ROW THEN STORE SESSION VARIABLE IN LOCALS TABLE ELSE RETURN
IF @AuthUserId = null
SessionVariable = @SessionVariable,
LastLoginDate = GETDATE()
WHERE (UserID = @UserID)
Basically in my application I would ask the user for a username and password. Then I would generate a random session variable.
I send everything to the stored procedure on SQL Server.
It's the stored procedure that does all the authentication and there is no way to read a password if not by compromising SQL Server and gaining SA privileges.
On the other hand the approach with salted hashes is different.
1- Retrieve the stored password and the salt for an user using a stored procedure.
2- Extract salt
3- Calculate salted hash of user provided password
4- Compare stored password with user provided
5- If they are the same call a stored procedure that given UserID writes a ticket in the database.
Step one means basically giving away the User table to anybody that can steal our connection string.
This in my opinion is a security problem because basically just by cracking the user of our connection string we can retrieve any password from any user. Of course it's hashed and salted and the malicious user has to guess a username but he can use a brute force attack to decode a password.
With the previous approach instead to use brute force attack he would have had to call the sored procedure once for every attempt. This would have slowed him down and would leave a trace in our logs of a suspect activity.
But since we cannot autheniticate from inside a stored procedure using Salted Hashes we have to retrieve the password. In this case an attacker can perform the brute force attack on his own computer without any delay from accessing our server through the internet and without leavin any trace.
Step five is even worst because one can just bypass the whole authentication system and authenticate himself. Of course we might sign our tickets using a keyed hash using the server private key so that the attacked cannot just generate a ticket.
What are your opinions to this approach. I have to say that I didn't come up with this but read it in Wrox C# Data Security Handbook so I'm surprised that a tested procedure seems so weak to me.
Last Visit: 31-Dec-99 18:00 Last Update: 30-Sep-22 22:08