Hi all,
Does anyone here have experience with using WineLib with FPC or Lazarus? Basically a company's application, that I'm doing a tender for, has licensed a Win32 DLL that they do not have the source for. They want their Delphi application ported to Mac OS X and Linux.

Tests show that using Wine/CrossOver that the DLL calls work correctly. What I'd like to do is Compile an FPC application with WineLib so that we can continue using this DLL.

The only other possibility would be to create C or Lazarus shared object that links to WineLib which in turn, talks to the DLL. Then my app would call the Shared Object on both Mac OS X and Linux and WineLib would do its magic.

Are either of these solutions possible? Is there a flaw in my plan?

Dominique

Hi,

I haven't used WiniLib but I have tested some Windows programs under Wine. My experience is that you are looking for trouble when using Wine. Many programs work only "almost" correctly, there are always some weird things happening. Even the programs that work are slow. The speed overhead can be huge, like ten times slower than under real Windows.

So, I recommend that you find some alternative method or library. There are many libraries available WITH source code. If they work in Delphi only, they can be ported to Lazarus / FPC.

When I programmed with Delphi I had a principle of never using a library without source code! Free or commercial, doesn't matter, it must have source code. I heard horror stories of companies who are forced to use Delphi 3 for some projects because they use a closed library without source code and the supplier went down already years ago.

Regards,
Juha Manninen

If it works in C, it should work in FPC, i'm not sure how many calls are needed for WineLib, Kylix used it and i don't think there should be any major problems, but if performance is important a replacement (native) library should be better.

Razvan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20091108/dad4d06e/attachment.html>

I did a quick reading in the wine website and it seams that winelib is designed to allow compiling applications in UNIX. Therefore I would expect that you build your application targeting linux, for example, but you ifdef out the Windows unit from the uses clause and adds a wine equivalent unit which would call the winelib shared object.

So to make this work you need to convert the headers for this winelib to Pascal, which AFAIK isn't done yet. Converting C headers is easy, and you can limit yourself to the routines you use, so it should be easy, although time consuming.

On Sun, Nov 8, 2009 at 7:52 PM, Felipe Monteiro de Carvalho <

WineLib replaces Windows system libs but also allows linking third party windows libs in a unix app.
At some point they even allowed using a native windows ntfs driver in Linux the same way ReactOS could use, Wine and ReactOS share parts of code.

So to make this work you need to convert the headers for this winelib

to Pascal, which AFAIK isn't done yet. Converting C headers is easy, and you can limit yourself to the routines you use, so it should be easy, although time consuming.

I'm not sure if static dll linking is possible under Linux if Wine is installed or Wine has dynamic linking but i think static linking should be possible too.

Razvan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20091108/a80b247d/attachment.html>

I'm not sure if static dll linking is possible under Linux if Wine is installed or Wine has dynamic linking but i think static linking should be possible too.

I don't know how it would be possible, maybe wine has it's own linker or something like that to make static dll linking possible?

Excluding that I would suppose they support only dynamic linking.

Hi all,
thanks for everyone's feedback.
Firstly the DLL in question cannot be easily replaced as the company who wrote it was bought by SAP and then that side of the business disappeared. So as far as I'm aware there is not way to replace that functionality and it really would take several multi-man years to rewrite it as it is quite a specialised library. The technology in question is called LinguistX.

I will look into if it is at all possible to link a Lazarus app with WineLib.

Dominique.

Hello!

A quick Google search for "LinguistX" gave me:

http://www.inxightfedsys.com/pdfs/LinguistX_FinalWeb.pdf

It seems to be made with C++ and it is multiplatform. Is it really not possible to get the library binaries or source any more? I understand they have discontinued the product's support but it should be possible to buy the library for other platforms, or better yet to buy its source code.
I guess they haven't deleted the source code permanently and someone has it. The list (below) does not mention Mac OS X, but if you get the sources it should be easy to port.

IMO, it just doesn't make sense to struggle with Wine when a native version of the library already exists.

Regards,
Juha Manninen

Copied from the web page:
----------------------------------

Supported Operating Systems and Compilers

? Solaris 8 and 9 on SPARC processors with GCC 3.2.3 and with Forte, 32 bit and 64 bit
? Red Hat Linux on Intel processors: ES 2.1 with GCC 2.96, AS 3.0 with GCC 3.2.3, and AS 4.0 with GCC 3.4.3
? SuSe Linux on Intel processors: Enterprise Server 9 with GCC 3.3.3 ? Windows 2000, XP and Server 2003 32 bit with MSVC 6.0 and Windows 2003 with MSVC 7.0
? AIX 5.2 on PPC processors with Visual Age 5.0
? HP-UX 11.11 on pa-RISC processors
with aCC A.03.33 and HPUX B.11.23 on Itanium processors with aCC a.05.52 for 32 bit and 64 bit architecture
LinguistX Platform Includes
? Windows DLL and Unix static library
? C++ API and sample applications

LinguistX Platform Includes

? Windows DLL and Unix static library
? C++ API and sample applications
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20091110/3a0c0366/attachment.html>