Native libpq.so instead of libpq.dll?

[Cigydd]

Hello all,

is it possible to use the native Linux libraries instead of their Windows builds?
This can be a newbie question.

I have a database program based on PostgreSQL and I think that coyping the Windows libraries for the application to run is a bit luxury when the same but native libraries with the same functions already exist for Linux and they are already installed on my system.

I tried to create a symlink from /usr/lib/libpq.so to libpq.dll in the application's directory but it didn't work.

Any help is gladly appreciated

[vitamin]

is it possible to use the native Linux libraries instead of their Windows builds?

Short answer - no.
Long answer - not directly. They most definitely will have different calling conventions, different structures, different ways to synchronize operations.

[Cigydd]

Hello vitamin,

thank you for your two responses in one post

This is what I didn't think of. I thought that a library developed for multiple platforms has just the same interface, the same function calls, structures etc. but you have educated me out of this wrong idea.

[Cigydd]

I was maybe misleaded by UnixODBC. It's an implementation of the ODBC database connection standard. It can be used even with WINE and it is a merely exact replacement of the Windows ODBC drivers. But it keeps a standard. It was intended and designed to have exactly the same library interface.
For other projects, the same functionality, data compatibility and a similar user inteface may be enough. They may not care about library interface compatibility.

[vitamin]

But it keeps a standard. It was intended and designed to have exactly the same library interface.

Even if it's _the same exact_ API it will definitely be different ABI. Also none of Windows synchronization objects exists on POSIX.

So at the minimum you looking for a thin "shim" dll that translates calls from/to system library as a fix for different ABI. At the maximum you looking for much extensive dll that synchronizes thread states, implements wrappers around wait functions, remaps data (ex: UTF8 <-> UTF-16).

[Cigydd]

This means that my view of cross-platform programming has still remained a bit naïve until now.
If I understand well there must be some "convertor" or intermediary, say, layer, maybe library. And is this what WINE does in particular?

[vitamin]

This means that my view of cross-platform programming has still remained a bit naïve until now.

If you using the same API and all you need is to recompile the program, that program indeed is a cross-platform. You can't avoid the compile part.

However, a program using Wine doesn't mean a cross-platform program. It's still a win32 program.

And is this what WINE does in particular?

No. Wine implements win32 API on top of POSIX, Xorg, and few more APIs.

[Cigydd]

You can't avoid the compile part.

This is obvious. I agree.

It's still a win32 program.

Yep.

And is this what WINE does in particular?

No. Wine implements win32 API on top of POSIX, Xorg, and few more APIs.

A bit lost here. This I already know and agree but what's then the principial difference between the mentioned "shim" library and WINE beside the amount of code?
Is it that the library would convert the Win32 calls to that of the ELF library and manage thread synchronization etc. but WINE doesn't convert, manage or synchronize anything - it just implements what the Win32 applications are trying to call, so the whole Win32 API…?

--Cigydd

[madewokherd]

If you want to develop cross-platform software, you shouldn't be using Wine.

You should be using only cross-platform API's, so that you can compile
the same code, without modification, for different operating systems
(which will have different executable formats and different ABI's).

If you want to distribute a single binary and have it work on multiple
platforms, use .NET/Mono.

Wine is a solution for when you have an existing windows-specific
codebase that is impossible or impractical to port.

[James McKenzie]

Cigydd wrote:

No. Wine implements win32 API on top of POSIX, Xorg, and few more APIs.

A bit lost here. This I already know and agree but what's then the principial difference between the mentioned "shim" library and WINE beside the amount of code?
Is it that the library would convert the Win32 calls to that of the ELF library and manage thread synchronization etc. but WINE doesn't convert, manage or synchronize anything - it just implements what the Win32 applications are trying to call, so the whole Win32 API…?

That is the goal and has been for many years (15+). Wine would allow you
to take a Windows32/Windows64 program and without any changes, install
it on top of Linux/Wine and run it as if it were a native program.

If you want to develop cross platform, you have to use a different
method. Cygwin/Mingwin are for moving UNIX/Linux code to Windows32/64.
.NET/Mono is for moving .NET 1.1/20./3.0 code from Windows32 to a
properly equipped UNIX/Linux/MacOSX environment. Of course, compilation
efforts must be expended and the code must be proper...

James McKenzie

[Gert van den Berg]

On Mon, Jul 19, 2010 at 02:54, Vincent Povirk <[email protected]> wrote:

If you want to distribute a single binary and have it work on multiple
platforms, use .NET/Mono.

O Java, where using the wrong version won't find you without an
"interpreter" (er... "runtime environment") for most operating
systems... (Mono does .NET 2.0 IIRC)

[madewokherd]

On Sun, Jul 18, 2010 at 11:16 PM, Gert van den Berg
<[email protected]> wrote:

O Java, where using the wrong version won't find you without an
"interpreter" (er... "runtime environment") for most operating
systems... (Mono does .NET 2.0 IIRC)

Mono does 3.5, and support for 4.0 is in development.

Of course, when working with any language that requires a "runtime
environment", it's a good idea to check what's in the stock install of
various operating systems and choose a version requirement based on
what people are likely to have.

From what I can tell, Java is not included at all in a stock Ubuntu
install or in a stock Windows install.

[vitamin]

but WINE doesn't convert, manage or synchronize anything -

Wrong, that is the major part of Wine's functionality.

it[Wine] just implements what the Win32 applications are trying to call, so the whole Win32 API…?

Yup, pretty much. Since there are no such things as DirectX for Linux Wine must implement that from the scratch.

[Martin Gregorie]

On Sun, 2010-07-18 at 23:33 -0500, Vincent Povirk wrote:

From what I can tell, Java is not included at all in a stock Ubuntu

install or in a stock Windows install.

I'd be surprised if OpenJava isn't included in Ubuntu distros - it is in
Fedora. However, like most developers, I use Sun/Oracle Java 1.6, which
is a free download and very easy to install for Linux or Windows.

Three ways of seeing if java is installed are:

<Code>

alternatives --display java # should mention Open Java as
# 'current best'

locate java # Lists all paths containing 'java'

java -version # Displays the installed version

</code>


Martin

[Cigydd]

but WINE doesn't convert, manage or synchronize anything -

Wrong, that is the major part of Wine's functionality.

OK, so then what's the principial difference?

it[Wine] just implements what the Win32 applications are trying to call, so the whole Win32 API…?

Yup, pretty much. Since there are no such things as DirectX for Linux Wine must implement that from the scratch.

Yes, absolutely.

--Cigydd

[vitamin]

OK, so then what's the principial difference?

Do you know the difference between file descriptor and a handle? If not, then there is no point in answering that question.

[Cigydd]

OK, so then what's the principial difference?

Do you know the difference between file descriptor and a handle? If not, then there is no point in answering that question.

And I fear there's no point in continuing this discussion.

[James Mckenzie]

Cigydd <[email protected]> wrote:

vitamin wrote:

Cigydd wrote:

OK, so then what's the principial difference?

Do you know the difference between file descriptor and a handle? If not, then there is no point in answering that question.

And I fear there's no point in continuing this discussion.

I've been like the fly on the wall, watching this discussion. Vitamin is correct in his statement. However, I will chime in with this: Wine is a psuedo-Windows environment with no current methodology to do what you are asking, that is directly access a dynamic library in the Linux/UNIX environment. However, if you are willing to rebuild your application, then you might want to look into using Winelib. However, this may not give you access from a Windows application to the functions and calls of a native Linux/UNIX file. What we do is provide an interface between what looks like a UNIX/Linux dynamic library (.dll.so file) and the Windows32/Windows64 API.

So, without alot of modification, Windows programs do not and cannot access Linux files directly. If you are working with a pure .NET application, you might want to look at using Mono to build your program. Since I'm not versed in Mono, you would have to ask if it is possible to do what you desire with their product in their forums.

James McKenzie

[Cigydd]

To be more specific on my cause, the application that I originally wanted to use the libpq.so is developed in Delphi 5 for Win32. So it would be too much work to port it to .NET/Mono.
My original question if it is possible to use native Linux libraries via Wine was clearly answered: No, it isn't possible because of different API and ABI.
If we decide to port it to Linux, the best solution is probably FreePascal and Lazarus IDE. That's cross-platform based and the Object Pascal dialects in Delphi and Lazarus are quite compatible. The ported application will then use native Linux libraries
In the meantime, we'll try to run our application under Wine on Linux, using the Win32 versions of the libraries.
I already found a small bug so look forward for it.
Thank the whole Wine team for such a great project.

[John Drescher]

To be more specific on my cause, the application that I originally wanted to use the libpq.so is developed in Delphi 5 for Win32. So it would be too much work to port it to .NET/Mono.
My original question if it is possible to use native Linux libraries via Wine was clearly answered: No, it isn't possible because of different API and ABI.
If we decide to port it to Linux, the best solution is probably FreePascal and Lazarus IDE. That's cross-platform based and the Object Pascal dialects in Delphi and Lazarus are quite compatible. The ported application will then use native Linux libraries
In the meantime, we'll try to run our application under Wine on Linux, using the Win32 versions of the libraries.
I already found a small bug so look forward for it.
Thank the whole Wine team for such a great project.

I am confused on why you do not just use the windows version of libpq
with your application and ignore the fact that the host os may or may
not have libpq installed.

John

[James Mckenzie]

Cigydd <[email protected]> wrote:

Sent: Jul 20, 2010 8:27 AM
To: [email protected]
Subject: [Wine] Re: Native libpq.so instead of libpq.dll?

To be more specific on my cause, the application that I originally wanted to use the libpq.so is developed in Delphi 5 for Win32. So it would be too much work to port it to .NET/Mono.
My original question if it is possible to use native Linux libraries via Wine was clearly answered: No, it isn't possible because of different API and ABI.
If we decide to port it to Linux, the best solution is probably FreePascal and Lazarus IDE. That's cross-platform based and the Object Pascal dialects in Delphi and Lazarus are quite compatible. The ported application will then use native Linux libraries
In the meantime, we'll try to run our application under Wine on Linux, using the Win32 versions of the libraries.

Thank you. Thus you do have a 'way forward' and thank you for supporting Linux as well as UNIX.

I already found a small bug so look forward for it.

Please also update the Applications Database. This will help those who develop using Delphi to avoid problem areas.

Thank the whole Wine team for such a great project.

You are welcome. Although I don't speak for the entire project, it has been a pleasurable discussion, a bit heated at times, but overall we came to a conclusion that works for the both of us and will help the project as well as you move forward.

James McKenzie

[Cigydd]

I am confused on why you do not just use the windows version of libpq with your application and ignore the fact that the host os may or may
not have libpq installed.

John

Don't search for any logic behind my obsession for native libraries
I just said to myself „I'm under Linux, could I make use of the libraries already installed? Do I have to copy the Windows ones? (They still take some space on the hard drive.) Could Wine be useful to serve as a bridge?“ I was just curious if it would be possible. And it isn't. I didn't even imagine what difficulties are hidden behind.

[Cigydd]

Thus you do have a 'way forward' and thank you for supporting Linux as well as UNIX.

You are welcome. GNU/Linux & Unix are the systems of my heart.

I already found a small bug so look forward for it.

Please also update the Applications Database. This will help those who develop using Delphi to avoid problem areas.

Good idea. Be sure I'll post our application there even when it's not commonly spread and supports only the Czech locale. It may be useful for other Delphists as you mention.

Thank the whole Wine team for such a great project.

You are welcome. Although I don't speak for the entire project, it has been a pleasurable discussion, a bit heated at times, but overall we came to a conclusion that works for the both of us and will help the project as well as you move forward.

James McKenzie

Yes. It's a pleasure for me to help anyhow with the development of Wine. My apologies for some sharp reactions.

[Cigydd]

Application posted into AppDB, waiting for acknowledgement.
You'll find it as WinMU.