DLL calling another DLL's functions (& other DLL questions)

Let's say I had a program (if you're wondering, I'm thinking about the pseudo-OS project I am going to play about with). The way I plan to write it is that there will be a bunch of "commands" written specifically for it that other modules (separate programs written into it) would be able to use themselves. These commands will be stored in DLLs as functions and declared/called when needed.

However, I am thinking about making it so that each "application" within the OS is actually a DLL file so people don't *have* to have everything loaded at once.

My first question is this: Can I have a DLL (application) loaded dynamically just by giving a command or function (something actually already in VB) to load (for instance) "dllaps1.dll" into program memory? Would I be able to write a DLL that was basically a program (with a form/forms, possibly?) in its own right and which could be loaded into the OS dynamically or is this too much work?

My second question: If, for instance, I was running text.exe (a text editor) and that called for an encrypt function in another DLL, would that DLL's data be exclusive to the calling DLL (text.exe) or would it be shared? What I am thinking is if I were using multiple programs using the same DLL file would they be interfering with each other? This is a possibility as some functions would be used often...I am trying to write it so that the functions provided in the DLL enhance the experience of using the actual OS and programming in it :-)

ActiveX exe and dll can do all of that. Don't ask me exactly how though! It was a long time ago... :sick:

Ages ago, a friend of mine (he used to post here too...he was the one that told me to start posting here so blame him) showed me that it could be done using APIs but never showed me *how*...what a sadist he is :-)

Not being able to declare an ActiveX functions (forcing you to recompile, for those who don't know) was my main reason for giving up making them (oh, the frustration...). The best I can remember now is using sub main if you didn't want to show the user interface, something about an instance of the dll being loaded into the apps memory space, referencing it - or adding the dll project to the main app. Oh, and version control... the list goes on..... (oh, copying/pasting the code into the exe(s), binning the dlls and going to the pub :lol: )

Quote:

---

Originally Posted by schoolbusdriver

(oh, copying/pasting the code into the exe(s), binning the dlls and going to the pub :lol: )

---

Going to the pub is part of the procedure for doing this?...this sounds like a very interesting process...tell me more :-)

Yeah, I had a feeling it was a difficult process to do, but as I said my friend showed me that I could run an EXE within a form (he had notepad instances running within a form and I could open as many notepads within it as I wanted) and said it was all done with APIs and stuff...just wouldn't tell me how :-)

In a way, that's a bit different to what I said I wanted as they're actually EXEs but EXEs work just as well as DLLs...as long as the EXE is written in such a way that it checks its parent (the form) to make sure it's not being run outside of it :-)

Quote:

---

Going to the pub is part of the procedure for doing this?

---

It's the most enjoyable part!! :bigyello:

I think (99.999% sure!) I know what your friend did... (heh, heh, heh...) (got to go to work, back later. You've 4 hours to think about it. heh, heh, heh...)

I could say "thinking is more work than asking others to think for me" but would probably be better to say "asking me to think is like asking someone not to think of a pink elephant" :-)

I have the basic idea of what they did...they basically embedded an executable into the form view somehow (so if the program was half-off the edge it would be half-visible in the form and not half out of it :-)) but I am about as good at APIs as politicians are at running (that's running not ruining) the country :-)

It would seem I'm not as smart as I thought (as usual :blush: ), but know there's a way of starting an app and specifying a window as the app's owner (I've seen this somewhere). After all, Windows does exactly that, and there's the "multiple desktops" apps out there too. The method I was thinking of was getting the handle of a running app and setting its parent to be another app that you create. So far I've managed to do the exact opposite :lol:

The following's more a curiosity than useful - unless you're a practical joker....

VB Code:

'Form1. Just has 2 buttons and a frame.
Option Explicit
 
Private Declare Function SetParent Lib "user32.dll" _
   (ByVal hWndChild As Long, ByVal hWndNewParent As Long) As Long
Private Declare Function FindWindow Lib "user32" Alias "FindWindowA" _
   (ByVal lpClassName As String, ByVal lpWindowName As String) As Long
Private Declare Function FindWindowEx Lib "user32" Alias "FindWindowExA" _
   (ByVal hWnd1 As Long, ByVal hWnd2 As Long, ByVal lpsz1 As String, _
   ByVal lpsz2 As String) As Long
 
Dim oldhwnd As Long  'Handle of Frame1s (former) parent - Form1.
Dim Progman As Long           '<
Dim SHELLDLLDefView As Long   '< Desktop hwnds
Dim SysListView32 As Long     '<
 
Private Sub Command1_Click()
'Get Desktop hwnd's.
   Progman = FindWindow("Progman", "Program Manager")
   SHELLDLLDefView = FindWindowEx(Progman, 0&, "SHELLDLL_DefView", vbNullString)
   SysListView32 = FindWindowEx(SHELLDLLDefView, 0&, "SysListView32", vbNullString)
 
'Move Frame1 onto the Desktop<<<<<<<<<<<<<<.
   oldhwnd = SetParent(Frame1.hwnd, SysListView32)
End Sub
 
Private Sub Command2_Click()
'Bring the frame back to Form1<<<<<<<<<<<<<<.
   SetParent Frame1.hwnd, Me.hwnd
End Sub

That pub's starting to tempt me again... ;)

The guy who did it before tells me it's something to do with setting the process's parent (or the EXE's parent) to the form you want it in, and it's something called MDI (multiple document interface) but beyond that, he's no use as he moved on from VB ages ago :-)