vb4linux-dev

[VB4Linux-Dev] OCXs

[James C. <ja...@st...>]

I'm lead to believe that OCX's are basically glorified DLL's.

To see if they are, open one up in a text editor and check if the first
two characters are 'MZ' or 'PE' (i can't as i'm running linux only).
Portable in PE means that the file is portable among the Windows family
of OS's, not different OS's or processor architectures.

Perhaps someone could try messing around with one in VB:
As far a i know, DLLs all have one function, called DllMain(). (Even if
you do not write this function when you are creating a DLL in VC++, an
empty one is automatically compiled anyway). You can think of this as a
constructor in Java. When the DLL is loaded, the OS calls DllMain (just
like it calls WinMain in applications). I'm sure there are some API
functions to get the functions a DLL exports but i don't know what they
are, GetProcAddress() i think). For example gdi32.dll exports
CreateCompatibleDC, so the code should be something like this:

	(Function names are not necessarily correct!)
	Dim hModule as Long
	Dim lpProc as Long

	hModule = LoadModule("c:/windows/system32/gdi32.dll");
	lpProc = GetProcAddress(hModule, "CreateCompatibleDC");
	...

Note: this is completely useless in VB as VB cannot Call pointers!

All this is just off the top of my head, check out msdn.microsoft.com
for better info.
Hope this helps somewhat.

Re: [VB4Linux-Dev] OCXs

[Scott B. <js...@go...>]

On Wed, 22 Nov 2000, James Cooper wrote:

> I'm lead to believe that OCX's are basically glorified DLL's.
They are.

> 
> To see if they are, open one up in a text editor and check if the first
> two characters are 'MZ' or 'PE' (i can't as i'm running linux only).
> Portable in PE means that the file is portable among the Windows family
> of OS's, not different OS's or processor architectures.
Thats correct.

> 
> Perhaps someone could try messing around with one in VB:
> As far a i know, DLLs all have one function, called DllMain(). (Even if
> you do not write this function when you are creating a DLL in VC++, an
> empty one is automatically compiled anyway). You can think of this as a
> constructor in Java. When the DLL is loaded, the OS calls DllMain (just
> like it calls WinMain in applications). I'm sure there are some API
> functions to get the functions a DLL exports but i don't know what they
> are, GetProcAddress() i think). For example gdi32.dll exports
> CreateCompatibleDC, so the code should be something like this:
A point dug out of this blurb....  I would not try and keep binary
compatibility between the OS platforms.  To me, the goal of this project is
to have a VB like system you can recompile your VB code on Linux or some
other Unix like OS, we want to use Wine, not be it.  Past that, you may
want to think about a VM, but I think most of this is beyond the scope of
this project, at first anyway.

> > 	(Function names are not necessarily correct!) 
> 	Dim hModule as Long
> 	Dim lpProc as Long
> 
> 	hModule = LoadModule("c:/windows/system32/gdi32.dll");
> 	lpProc = GetProcAddress(hModule, "CreateCompatibleDC");
> 	...
> 
> Note: this is completely useless in VB as VB cannot Call pointers!
For this, all we will do is generate the load .so function for the
specified function.

scott

Re: [VB4Linux-Dev] OCXs

[Martino S. <ms...@ti...>]

----- Original Message -----
From: "James Cooper" <ja...@st...>
To: "VB4Linux Project" <vb4...@li...>
Sent: Wednesday, November 22, 2000 11:15 AM
Subject: [VB4Linux-Dev] OCXs


> I'm lead to believe that OCX's are basically glorified DLL's.
>
> To see if they are, open one up in a text editor and check if the first
> two characters are 'MZ' or 'PE' (i can't as i'm running linux only).
> Portable in PE means that the file is portable among the Windows family
> of OS's, not different OS's or processor architectures.

Perfect.

> Perhaps someone could try messing around with one in VB:
> As far a i know, DLLs all have one function, called DllMain(). (Even if
> you do not write this function when you are creating a DLL in VC++, an
> empty one is automatically compiled anyway). You can think of this as a
> constructor in Java. When the DLL is loaded, the OS calls DllMain (just
> like it calls WinMain in applications). I'm sure there are some API
> functions to get the functions a DLL exports but i don't know what they
> are, GetProcAddress() i think). For example gdi32.dll exports
> CreateCompatibleDC, so the code should be something like this:
>
> (Function names are not necessarily correct!)
> Dim hModule as Long
> Dim lpProc as Long
>
> hModule = LoadModule("c:/windows/system32/gdi32.dll");
> lpProc = GetProcAddress(hModule, "CreateCompatibleDC");
> ...

This is correct if you have a Common DLL written by C. You get the proc
address and use it,
but the OCX use the COM interface (like CORBA) to share objects to any
application that request them.
Beside this, you must know the objects that the OCX share. If you don't
know, the OCX share, with a common interface, a Type Library (.TLB), that
have stored the object definition.


P.S.: I don't know if my english is plain. I'm sorry.

>
> Note: this is completely useless in VB as VB cannot Call pointers!
>
> All this is just off the top of my head, check out msdn.microsoft.com
> for better info.
> Hope this helps somewhat.
> _______________________________________________
> VB4Linux-Dev mailing list
> VB4...@li...
> http://lists.sourceforge.net/mailman/listinfo/vb4linux-dev

RE: [VB4Linux-Dev] OCXs

[Abhijit P. <abh...@ma...>]

I checked some .dll files...they were starting with "MZ" and so do the OCX
files.
Now what does this mean?

Apart from the OCX / DLL support in VB, we could come up with
support for the GNOME Object Model (bonobo) and KDE's KOM, or other
technologies based on CORBA.

ab

Re: [VB4Linux-Dev] OCXs

[James C. <ja...@st...>]

> 
> I checked some .dll files...they were starting with "MZ" and so do the OCX
> files.
> Now what does this mean?

This means that the files are just like normal .exe files. At the start of
a .exe file there are a couple of information headers (except for .com or
.sys files which are pure machine code.) They contain info about the
linker used, the timestamp, etc and most importantly, the start of the
machine code. Quickview reads this info when 'quickview'ing a DLL or EXE.
I read an article on MSDN on deciphering this info but i have no idea in
which section. I might have a hard-copy and will put it on my web-page if
i find it. It might be useful, you never know.

 > 
> Apart from the OCX / DLL support in VB, we could come up with
> support for the GNOME Object Model (bonobo) and KDE's KOM, or other
> technologies based on CORBA.
>

I haven't a clue how to use KOM, COM, or bonobo. 
 
> ab
> 
> _______________________________________________
> VB4Linux-Dev mailing list
> VB4...@li...
> http://lists.sourceforge.net/mailman/listinfo/vb4linux-dev
>