Delphi FS Module [with FSUIPC]

[EsCaPe]

Hi to all,

I created Delphi DLL module but I have one problem...Delphi SDK has no access to Open2() function so I can not register my module withn FSUIPC using Inter-Process

I attached test project to create delphi DLL for FS...

Does anyone knows is there any way to use "Library for FS Internal Users" with Delphi app so I can register my module...

Or maybe creating some C DLL and linking Delphi to it...anything will help...

This means me a LOT because I am working on huge project for FS VA Community...non-comercial program software

Unfortunatelly, I crated external application before I tested Delphi's ability to use Inter-Process registration....Please help people...

Thanks a lot...

Marko

escape@cg.yu

module.zip

[Pete Dowson]

Does anyone knows is there any way to use "Library for FS Internal Users" with Delphi app so I can register my module...

That would certainly be the best way, if it is possible.

Or maybe creating some C DLL and linking Delphi to it...anything will help...

That is a little more problematic. If the DLL resides in the FS Modules folder it will have to be named other than a DLL -- I know C programs can link to any DLL even by a different name, but can Delphi?

I think, if it is resolved this way then you might need to place the C DLL you are using into a separate folder of your own creation, and explicitly point your code at it at run time.

There are two further alternatives which could be considered:

1. I could supply the C source for the Module User's library, for conversion to Delphi, and thence presumably building into your module in place of whatever you have now. Most of the code is similar, it is mainly the "Process" call which is different, abd of course the Open2 call in that you provide the memory, whereas for an external program the memory is a "memory-mapped file" opened with Windows.

There are two small problems with this approach -- the first is finding someone who knows both C and Delphi to do the work, and the second is that the calling sequence into FSUIPC, in the Process routine, does involve a very small amount of Assembly Code which is designed to provide essential information in the call. I don't know if what it needs to do is possible in Delphi.

2. I could have a look to see if I can (or should) build the interface C procedures (Open2, Read, Write, Process and Close) into FSUIPC.DLL as exports which you can link to directly from your DLL. In other words, rather than attempt to make a separate DLL with the ensuing problems I describe above, expand FSUIPC itself to BE that DLL.

I don't mind doing this last change, though I am only prepared to do it if it is indeed possible for Delphi to actually link to and use such procedures. I'm afraid my knowledge of Delphi is so poor I do not know. Perhaps you could investigate this and advise?

There is another problem arising with this last alternative in any case -- obviously I have to find time to build in the code (possibly within a week or so, but I'll not know till Monday), and you would need to stipulate to your Module users that they must have version x of FSUIPC or later.

Let me know your thoughts and we'll proceed from there. Did you contact Pelle, by the way?

Regards,

Pete

[EsCaPe]

I know C programs can link to any DLL even by a different name, but can Delphi?

As i know it can, because I must type whole file name in LoadLibrary function.

I think, if it is resolved this way then you might need to place the C DLL you are using into a separate folder of your own creation, and explicitly point your code at it at run time.

For last few days I am doing my best to find some alternative...Maybe the least painful option will be if I find Borland C++ Module Example (DLL) because I can use my previous knowledge from Delphi to use Borland C++

1. I could supply the C source for the Module User's library, for conversion to Delphi...

I have C source provided with SDK

There are two small problems with this approach -- the first is finding someone who knows both C and Delphi to do the work, and the second is that the calling sequence into FSUIPC, in the Process routine, does involve a very small amount of Assembly Code which is designed to provide essential information in the call. I don't know if what it needs to do is possible in Delphi.

I noticed one ASM part...I think that Delphi is also able to use asm code...Ill check it out...

2. I could have a look to see if I can (or should) build the interface C procedures (Open2, Read, Write, Process and Close) into FSUIPC.DLL as exports which you can link to directly from your DLL. In other words, rather than attempt to make a separate DLL with the ensuing problems I describe above, expand FSUIPC itself to BE that DLL.

I dont want you to do something yet because I am not 100% sure that I know how to call a function from DLL writen in C.

Ill try to build some small C DLL example and use it by Delphi app...

Perhaps you could investigate this and advise?

Yes...that was my idea too...ill spend few more days trying to find out some solution...If I dont find it, then I will probably use some other addons instead of FSUIPC for internal module, and small C programs (external...called by internal module) for some routines (fuel loading and etc.)...until I found some solution or create module in C++...anyway, FSUIPC is the best so sooner or later I will find out way to use FSUIPC in my project...

Did you contact Pelle, by the way?

I wrote a PrivateMessage same day you told me about him, but no answers yet...I cannot find his email...could you provide it to me via PM or email (escape@cg.yu) so I can contact him...

Thanks a lot Pete

Marko

----------------------------------

SEA - Software Development

http://www.skyeast-va.com

----------------------------------

[Pete Dowson]

1. I could supply the C source for the Module User's library, for conversion to Delphi...

I have C source provided with SDK

Ah, yes, so you do. I forgot that I provided everything for that too.

I dont want you to do something yet because I am not 100% sure that I know how to call a function from DLL writen in C.

Well, of course most if not all of Windows itself is written in C or C++ and all the APIs your program is using come from Windows DLLs like USER32.DLL, GDI32.DLL, KERNEL32.DLL etc.

Did you contact Pelle, by the way?

I wrote a PrivateMessage same day you told me about him, but no answers yet...I cannot find his email...could you provide it to me via PM or email (escape@cg.yu) so I can contact him...

I've written to him already and asked him to look at this thread. He is pursuing investigations into what can be done at present, like you. ;-)

Regards

Pete

[EsCaPe]

I've written to him already and asked him to look at this thread. He is pursuing investigations into what can be done at present, like you. ;-)

Delphi is very easy to understand and manipulate so soloving this problem will probably help few more people than me :)

Delphi's main linking to system libraries (USER, KERNEL and etc) are automatic so there is no visible source or something simmilar where I can se how it works..

For now, I can link Delphi APP with DLL built by Delphi...today Ill play with C DLLs and Delphi...

Any progress I'll provide source here to help someone else with same problem (if there is such people) :)

Tnx

Marko

[Pete Dowson]

Delphi is very easy to understand and manipulate so soloving this problem will probably help few more people than me :)

Pelle has confirmed that he knows no way to bind Delphi to C/C++ LIB files.

He does, however, specifically say that should be no problem linking to DLLs. He says "there shouldn’t be any problem using functions from other DLL’s from within a Delphi program/DLL. I admit I haven’t done much programming using DLL’s (I normally place all my code in the EXE, making it easier to “distribute” the application), however I don’t think Delphi will have any issues with DLL’s that are not called DLL (for instance formally ActiveX are DLL’s with the extension OCX and these can be used in Delphi without any problem)."

For now, I can link Delphi APP with DLL built by Delphi...today Ill play with C DLLs and Delphi...

Okay. All you should need is the equivalent of LoadLibrary() and GetProcAddress(). These allow you to link at run time, without a disastrous failure (FS crash) should the DLL not be available or not have the procs you need exported. Here's an example in C (this is how it would be if I build the library into FSUIPC.DLL)::

HMODULE hInstFSUIPC;
BOOL (WINAPI *pFSUIPC_Open2)(DWORD, DWORD *, BYTE *, DWORD) = 0;
BOOL (WINAPI *pFSUIPC_Process)(DWORD *) = 0;
BOOL (WINAPI *pFSUIPC_Read)(DWORD, DWORD, void *, DWORD *) = 0;
BOOL (WINAPI *pFSUIPC_Write)(DWORD, DWORD, void *, DWORD *) = 0;
BOOL (WINAPI *pFSUIPC_Close)(void) = 0;

...

hInstFSUIPC = LoadLibrary("FSUIPC.DLL");
(DWORD) pFSUIPC_Open2 = (DWORD) GetProcAddress(hInstFSUIPC, "FSUIPC_Open2"); 
(DWORD) pFSUIPC_Process = (DWORD) GetProcAddress(hInstFSUIPC, "FSUIPC_Process"); 
(DWORD) pFSUIPC_Read = (DWORD) GetProcAddress(hInstFSUIPC, "FSUIPC_Read"); 
(DWORD) pFSUIPC_Write = (DWORD) GetProcAddress(hInstFSUIPC, "FSUIPC_Write"); 
(DWORD) pFSUIPC_Close = (DWORD) GetProcAddress(hInstFSUIPC, "FSUIPC_Close"); 

Then you should check that all five of these results are non-zero. This confirms that you have the addresses of the routines you need.

At the end of the program use FreeLibrary(hInstFSUIPC);

When you want to actually use any of these FSUIPC routines, you call them via the pointers. For example, again, in C:

(*pFSUIPC_Close)();

The * dereferences the pointer so the call actually does go to the address contained in the variable called pFSUIPC_Close.

I am sending this to Pelle too, in case you need help understanding how to do this is Delphi. It would be much easier to link to the DLL unconditionally, as you would to you own DLLs or Windows, but then you crash FS if the wrong version of FSUIPC is there, or no FSUIPC is there at all. You can check these things easily with the above code.

Let me know when you decide what to do. I don't think I would have any problem adding these exports to FSUIPC, but of course I'd need to check that first, and also make sure there was no adverse affect on FS itself. I don't think it checks for other exports, but you never know! ;-)

Regards,

Pete

[EsCaPe]

He does, however, specifically say that should be no problem linking to DLLs. He says "there shouldn’t be any problem using functions from other DLL’s from within a Delphi program/DLL.

This is totally convinient....

Okay. All you should need is the equivalent of LoadLibrary() and GetProcAddress(). These allow you to link at run time, without a disastrous failure (FS crash) should the DLL not be available or not have the procs you need exported.

There is same functions in Delphi for loading DLL library

With your code changes I think that there won;t be any problem but I suggest that (if it is not a problem and takes you less time) you create separate DLL that will act as processor betwen "Some APP" and FSUIPC

This resolves FSUIPC version problem...user is not required to download new version.

I don't know is this possible but I think that it is much better solution

It would be much easier to link to the DLL unconditionally, as you would to you own DLLs or Windows, but then you crash FS if the wrong version of FSUIPC is there, or no FSUIPC is there at all.

Delphi is able to use LoadLibrary (explicit linking)

Let me know when you decide what to do. I don't think I would have any problem adding these exports to FSUIPC

Few more days reasrching and will see what will happen...I am going little crazy because of all these Pascal, C, C++ codes but...It is the risk I am ready to take :D

Beest Regards

Marko

[Pete Dowson]

With your code changes I think that there won;t be any problem but I suggest that (if it is not a problem and takes you less time) you create separate DLL that will act as processor betwen "Some APP" and FSUIPC

This resolves FSUIPC version problem...user is not required to download new version.

I don't know is this possible but I think that it is much better solution

Actually, I don't like that for several reasons:

1. It cannot be named a DLL, or else must go elsewhere than in the FS Modules folder

2. It means more packaging for the software author and more to install / uninstall for the user

3. It is actually a lot more work for me to produce a new DLL in any case.

4. It would be yet another module for me to maintain and support.

5. The code is so small (miniscule), it would fit into FSUIPC without even noticing.

Additionally, if it forces more folks to update to the latest supported version of FSUIPC I like it better. A lot of my support time is wasted trying to help folks using older versions before I find out they are! ;-)

Few more days reasrching and will see what will happen...I am going little crazy because of all these Pascal, C, C++ codes but...It is the risk I am ready to take :D

Okay,

Regards,

Pete

[EsCaPe]

http://en.wikipedia.org/wiki/Microsoft_nk_Library

I found what I need...this explanes me some things...

Ill try now to compile Internal-User Library as DLL with few changes...and execute functions from Delphi...

Wish me a luck :D

[EsCaPe]

Hi Pete....

I built DLL that can be used to communicate with FSUIPC for External Modules (FSUIPC_Open() function)

I attached changed version of library found in SDK...it is now in TOTAL MESS because I was only testing and I am not any kind of pro in C :D

I will appritiate if you take a look and check if it is everything OK...

I chenged my External module source code to use that DLL to communicate with FSUIPC...and it works almoast perfect....only think that went wrong is Fuel Capacity....but...maybe that was my mistake (variable type)

I will now try to recompile Inter-Process Library....

Bye

Marko

FSUIPC.ZIP

[Pete Dowson]

I built DLL that can be used to communicate with FSUIPC for External Modules (FSUIPC_Open() function)

I attached changed version of library found in SDK...it is now in TOTAL MESS because I was only testing and I am not any kind of pro in C :D

All that is in there are a thing called "test.cpp" and my own header files. I can see that the "cpp" file has DLL things added, but what "TOTAL MESS" have you made? Am I supposed to compare the code line-by-line? I'm not sure what you need me to check?

I will now try to recompile Inter-Process Library....

I assume you mean "intra-process"? Inter-process is what you want with separate processes. ;-)

Does this mean you don't agree with me adding the exports into FSUIPC?

Regards,

Pete

[EsCaPe]

I assume you mean "intra-process"? Inter-process is what you want with separate processes. ;-)

Yes :) intra-process

Does this mean you don't agree with me adding the exports into FSUIPC?

Well, I am trying to find slution because I don't want you to change FSUIPC only because of me...

I am having trouble now rebuilding Library for Internal users...I rebuilded it but I get Access Violation error...working on it...

Regards

Marko

[EsCaPe]

Today, I tried to translate C code to Delphi....I have few code problems....maybe you can help..

asm
     push eax
[b]     call next
     next: pop eax[/b]
     mov dwError,eax
     pop eax
end;

Compiler does not recognise "next" in both lines.....is there any alternate to this code or something else ?

Also, I have problem with:

dwError = SendMessage(m_hWnd, WM_IPCTHREADACCESS, (WPARAM) (m_pNext - m_pView - 4), (LPARAM) m_pView);

I see that WM_IPCTHREADACCESS is #define WM_IPCTHREADACCESS (WM_USER+130) but there is no WM_USER definition in Delphi...

I also found that WM_USER is 0x0400 ($0400 in Delphi)...is that correct ?

How to use this?

I was playing a little with a code (without knowing what am I doing) and when i set this:

dwError := SendMessage(m_hWnd, RegisterWindowMessage(FS6IPC_MSGNAME1), WPARAM(DWORD(m_pNext) - DWORD(m_pView) - 4), LPARAM(m_pView)); //(Delph code)

i get 89844 IPC ERROR: Atom Id not recognised in FSUIPC LOG

when i set this:

dwError := SendMessage(m_hWnd, RegisterWindowMessage(FS6IPC_MSGNAME1), WPARAM(1), LPARAM(m_pView)); //(Delph code)

i get 666594 IPC ERROR: Offset >= 65534 in FSUIPC LOG

It is possible that I am not calling Open2 in a right way...please provide me a simple code for calling it....just to check...

...this is only moment when FSUIPC detect some action...maybe that can help you to see what I am doing wrong...

My cable connection expires today so I'll be back by tonight...I hope I'll find out something else till then...

Bye

Marko

[Pete Dowson]

Compiler does not recognise "next" in both lines.....is there any alternate to this code or something else ?

It's just a label. If you cannot use labels can you refer to the places to jump to or call by relative position, eg $ = here or * = here? If the assembler part of Delphi can't support labels or relative address then it is useless it acccepting the call in the first place. See if you can do call $ or similar, but make sure it calls the next instruction, e.g. *+2 or whatever.

There are other ways of doing what I'm doing here, but I suspect not without needing changes to FSUIPC itself to make it check things differently.

I see that WM_IPCTHREADACCESS is #define WM_IPCTHREADACCESS (WM_USER+130) but there is no WM_USER definition in Delphi...

I also found that WM_USER is 0x0400 ($0400 in Delphi)...is that correct ?

How to use this?

Since WM_USER is 0x0400, which is 1024 in decimal, you can either define WM_IPCTHREADACCESS to be 1154 (i.e. 1024 + 130) or simply use 1154 directly.

I was playing a little with a code (without knowing what am I doing) and when i set this:

dwError := SendMessage(m_hWnd, RegisterWindowMessage(FS6IPC_MSGNAME1), WPARAM(DWORD(m_pNext) - DWORD(m_pView) - 4), LPARAM(m_pView)); //(Delph code)

i get 89844 IPC ERROR: Atom Id not recognised in FSUIPC LOG

when i set this:

dwError := SendMessage(m_hWnd, RegisterWindowMessage(FS6IPC_MSGNAME1), WPARAM(1), LPARAM(m_pView)); //(Delph code)

i get 666594 IPC ERROR: Offset >= 65534 in FSUIPC LOG

Where does any of that come from? There is no RegisterWindowMessage needs in the module users access. -- you have the code, you should know that already! None of that registered message, atoms, mapped memory file stuff is used at all in FS DLLs and Gauges. Why are you still messing with the external library code?

Regards

Pete