Author Topic: ODIN - loading DLLs  (Read 7028 times)

Doug Clark

  • Sr. Member
  • ****
  • Posts: 306
  • Karma: +7/-1
    • View Profile
ODIN - loading DLLs
« on: May 01, 2019, 07:07:20 pm »
Does ODIN know the "type" (windows vs OS2) of DLL and load both types automatically?

Meaning: if I have a windows program I have created called MYPROGRAM.EXE, and start that program using PE.EXE, can that program call functions located in DLLs compiled for OS/2 by an OS/2 compiler?

Conversely: If I have an OS/2 program, MYPROGRAM2.EXE, which is compiled for OS/2 and started the normal way (i.e from a command prompt, etc.), can that program call functions located in a Windows DLL?

Finally - if either program needs a function located in a DLL, and there is both an OS/2 type and Windows type DLL with the same name located on the LIBPATH, which one gets loaded? Or the same name (but a different type) already loaded into memory?

Pete

  • Hero Member
  • *****
  • Posts: 1281
  • Karma: +9/-0
    • View Profile
Re: ODIN - loading DLLs
« Reply #1 on: May 01, 2019, 08:27:18 pm »
Hi Doug

I am not an odin expert but would expect windows apps to be limited to using windows dll files - I think that is what the windows app coders expect as well.

And vice versa re: os2/ apps calling windows dll files.

Finally: Possibly an error message about wrong dll file.


Regards

Pete



Doug Clark

  • Sr. Member
  • ****
  • Posts: 306
  • Karma: +7/-1
    • View Profile
Re: ODIN - loading DLLs
« Reply #2 on: May 01, 2019, 11:27:27 pm »
Sadly Pete is appears you are correct.

Knowing nothing about how each respective operating system loads DLL and programs up and executes them, it seems strange to be able to run an entire Windows program in ODIN, but not just the DLLs. I am also guessing the ODIN itself makes the transition from Windows DLLs to OS/2 DLLs internally at some point; otherwise ODIN would have to replicate the entire Windows OS in order to run any programs.

If we could call Windows DLLs from OS/2 programs this would open up a whole universe of possibilities. I am thinking specifically of ODBC - OS/2 programs being able to call into ODBC32.DLL  and related DLLs (the Windows version). This would not only bring our ODBC version up to date, but would probably make it possible, perhaps even easy, to move databases such as Postgres, Firebird, Interbase, etc. directly from Windows to OS/2.  (I am guessing that most databases use the subset of APIs that works in ODIN.) Or maybe the Postgres ODBC driver from windows to OS/2 and use that to access the OS/2 version of Postgres that Paul Smedly has ported (for example). It would mean we could use OS/2 as a client for the very latest versions of DB2 or Oracle or most other databases.

Oh well - it was  a nice dream.


I have attached two zip files: hellow.zip and hello2.zip.  The hellow.zip contains hellow.exe and hellox.dll - both compiled on Windows (Win 7 actually). Hello2.zip contains hello2.exe and hellox.dll - both compiled on OS/2 (aos).

On OS/2
pec hellow.exe works with the windows version of hellox.dll, but errors with the OS/2 version of hellox.dll "Failure to load hellow.exe due to bad or missing HELLOW.EXE"
(The message is wrong but I understand their error)

source for Hello2.exe / hellow.exe
---------------------------
void sayHello(void);
int main()
{
  sayHello();
  return 0;
}

-----------------------------
Source for hellox.dll

void sayHello(void)
{
   cout << "Hello from the DLL" << endl;
}
--------------------------------------------------


Dave Yeo

  • Hero Member
  • *****
  • Posts: 4786
  • Karma: +99/-1
    • View Profile
Re: ODIN - loading DLLs
« Reply #3 on: May 02, 2019, 02:30:13 am »
There was win2k.sys (xxx2k.sys IIRC in its last incarnation before being dropped) that allowed loading Windows DLLs amongst other things. There was also xx2lx.exe to convert windows DLLs into OS/2 DLLs. Unluckily testing xx2lx with your hellow.exe and hellox.dll results in both crashing xx2lx, likely due to using newer Odin libraries.
You'd still have problems calling functions in a Win DLL from OS/2, ranging from calling convention to lack of matching crt. Best is to recompile, linking against Odin as far as I know.

Doug Clark

  • Sr. Member
  • ****
  • Posts: 306
  • Karma: +7/-1
    • View Profile
Re: ODIN - loading DLLs
« Reply #4 on: May 02, 2019, 05:07:16 am »
Dave,


One of the ideas I am toying with is getting Delphi 4 to run in ODIN, and
the applications created with Delphi 4 to also run on ODIN. As you probably know
Delphi (at least version 4) uses the Borland Database Engine (BDE). If you want to
access ODBC data sources you must do that through the BDE, or write you own access routines.

Delphi-> BDE -> ODBC -> database driver

For "flat file" databases - xBase, Paradox, text - BDE has its own
internal routines - which appear from the limited testing I have done
to work in ODIN.

The problem is accessing ODBC, because the BDE is calling the Windows ODBC dlls.
One possible solution, assuming the Windows ODBC "stack" will work on ODIN,
is to have parallel ODBC systems that never cross: 1 for OS/2 and 1 for Win32. This is actually how
it works in Win-OS2.

But that means in order to access DB2, for example, you have to install the OS2 client (CAE) to access
from OS2 programs, the windows version of the client to access from ODIN type apps, and the Win16 client to
use Win-OS2 programs. Obviously painful.

I am telling you all this hoping it will trigger some brilliant suggestion. (Apps use the same calling
convention to call ODBC functions in both Win32 and OS/2.)

The pict shows a small Delphi created app running in ODIN displaying dBase data. The table contains about 30k rows.

ivan

  • Hero Member
  • *****
  • Posts: 1557
  • Karma: +17/-0
    • View Profile
Re: ODIN - loading DLLs
« Reply #5 on: May 02, 2019, 02:05:06 pm »
Talking about Odin DLLs, does anyone know how to convert real win XP DLLs so they can be used by Odin?  I have a program that displays the output of my weather station but it runs on windows only so I am reduced to using a dual boot setup to run XP.

Pete

  • Hero Member
  • *****
  • Posts: 1281
  • Karma: +9/-0
    • View Profile
Re: ODIN - loading DLLs
« Reply #6 on: May 02, 2019, 05:01:02 pm »
Hi All

Years back I tried running something possibly called NTI CD Burner (definitely similar) via odin pe.exe
It failed due to a "wrong" dll file being supplied by odin. I backed up the odin supplied dll file and replaced it with the WindowsXP version.

That worked - but only for that application.

I also discovered that the Acrobat5 installation provided a better way of running windows apps than odin itself. Details escape me at the moment but I think for OpenOffice 1.1.5 I had a program object for Acrobat with office.exe as the parameter. I guess I could try and find an old setup to check what I did exactly - you may find this using Google as I posted it in several newsgroups.


@Doug
I am not sure how complete database components are in WDsibyl - https://www.wdsibyl.org/ - but that is the closest thing on OS/2 to Delphi. It may be worth looking into.


Regards

Pete


Doug Clark

  • Sr. Member
  • ****
  • Posts: 306
  • Karma: +7/-1
    • View Profile
Re: ODIN - loading DLLs
« Reply #7 on: May 02, 2019, 05:23:03 pm »
As an alternative you could try a low power fanless WinXP box.

I have a USB telephone system that will only run on real WinXP - not in Virtual PC or vbox - because of the USB drivers. I am running it on an HP Thin Client T610 - which consumes a little less than 15 watts. The HP T510 or HP T5740 use around 12 watts, and are cheaper. It cost $35 on ebay, plus $5 for a USB stick (I actually installed a very cheap SSD instead for $25 for other reasons). Embedded WinXP is free to download from the HP site.  Install VNC server, and/or hook to a KVM, and you can monitor your weather station.

I also run a home automation system that has a visual programming feature on the same machine, which is why I put the SSD in instead of a USB stick and went with the slightly faster T610. Otherwise I would have used the cheaper slower t510 or t5740.

Plus is you don't have to dual boot. Minus is you are spending 12 to 15 watts, plus the initial cost of $40.

xynixme

  • Guest
Re: ODIN - loading DLLs
« Reply #8 on: May 02, 2019, 09:39:46 pm »
But that means in order to access DB2, for example, you have to install the OS2 client
Or perhaps a Windows-"solution" which supports both ODBC and TDS. Not sure if e.g. FreeTDS is portable and could access any ODBC database via such a solution.

Disclaimer: I'm using not using any standard or third-party file format to access my own data.

Doug Clark

  • Sr. Member
  • ****
  • Posts: 306
  • Karma: +7/-1
    • View Profile
Re: ODIN - loading DLLs
« Reply #9 on: May 02, 2019, 10:10:13 pm »
Dave - thanks for running that through xx2lx - and the interesting suggestion to try an earlier release of ODIN/xx2lx.exe and see what happens.

Pete - thanks for reminding me about WDSibyl. I will check that out.

Andre - Since MS SQL Server already has an ODBC driver available for Windows, I don't think freeTDS buys you much - unless you are remotely doing database administrator stuff like creating new databases, running statistics, etc. ODBC can't do that, where (an app running through) freeTDS potentially might. But you would probably have to be running the SQL Server yourself on your own machine, otherwise the chances of getting remote access (authorization) for database administration are - well, remote.

ivan

  • Hero Member
  • *****
  • Posts: 1557
  • Karma: +17/-0
    • View Profile
Re: ODIN - loading DLLs
« Reply #10 on: May 03, 2019, 05:57:12 pm »
Doug and Pete,

Thanks, your information got me thinking of alternative ways to get the results.  The original program has been taken over by another developer and is well on the way to being a universal application working on Windows, Linux and OS X, apparently it also runs on a  Raspberry Pi. The output is to a webserver and the latest version (May 1st) now works on my Ryzen based Linux Mint box but requires installing Mono to get the display of the gauges (they don't display on OS/2 / ArcaOS).