Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT sourceware DOT cygnus DOT com>
List-Archive: <http://sourceware.cygnus.com/ml/cygwin/>
List-Post: <mailto:cygwin AT sourceware DOT cygnus DOT com>
List-Help: <mailto:cygwin-help AT sourceware DOT cygnus DOT com>, <http://sourceware.cygnus.com/ml/#faqs>
Sender: cygwin-owner AT sourceware DOT cygnus DOT com
Delivered-To: mailing list cygwin AT sourceware DOT cygnus DOT com
X-Authentication-Warning: hp2.xraylith.wisc.edu: khan owned process doing -bs
Date: Mon, 24 Jan 2000 20:49:55 -0600 (CST)
From: Mumit Khan <khan AT NanoTech DOT Wisc DOT EDU>
To: "Gordon Watts (UW Seattle)" <gwatts AT fnal DOT gov>
cc: Gnu-Win Cygnus Mailing List <cygwin AT sourceware DOT cygnus DOT com>
Subject: Re: Calling cygwin32_conv_to_full_win32_path from a MSVC app
In-Reply-To: <000301bf5d36$11ce8eb0$c55e5f80@fnal.gov>
Message-ID: <Pine.HPP.3.96.1000124203149.1999G-100000@hp2.xraylith.wisc.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Wed, 12 Jan 2000, Gordon Watts (UW Seattle) wrote:

> Hi,
>   I'm trying to convert from UNIX paths to NT paths inside an app that has
> been built under MSVC. I was hoping to do this by pulling in the
> cygwin19.dll and then calling the conversion function.
>   I can see from the mailing list (I used egroups, which had the best
> message interface that I saw, to do the search) that this has been discussed
> quite a bit. After an hour of looking I wasn't able to fix the problem. Here
> is what I'm doing now.

You can actually do what you need via a "shim" DLL that is dependent on 
Cygwin. However, you'll need a recent Cygwin DLL (circa 2000-01-06 or so),
otherwise may get seg faults.

The idea is the following:

1. Find the Cygwin calls you need, which in this case are just the path
   conversion routines.

2. Write a Cygwin DLL that exports a set of "WINAPI" functions, which in
   turn call the Cygwin counterparts. The WINAPI/STDCALL is needed to
   load and execute using LoadLibrary/GetProcessAddress duo in the next
   step.

3. From your Mingw/MSVC app, load this DLL using Loadlibrary, and then
   use GetProcAddress to call the exported functions (from step 2), and
   it should work, at least in theory.

This is of course all without doing any testing, so your mileage will
certainly vary.

Here's rough draft of what you may need to do:

Step 2: write the "shim" DLL.

  /* Declare the Cygwin functions that we need. */
  extern int cygwin_conv_to_win32_path (const char *, char *);
  
  /* This is the interface function that non-Cygwin clients call. */
  __declspec(dllexport) __stdcall int
  conv_to_win32_path (const char *cygwin_path, char *win32_path)
  {
    return cygwin_conv_to_win32_path (cygwin_path, win32_path);
  }


Build the DLL using Cygwin GCC:
  
  $ gcc -c shim.c
  $ dllwrap -o shim.dll --target=cygwin32 shim.o

  [ 
    for the next version, you can do the following:
    $ gcc -shared -o shim.dll shim.o
  ]

Now, in your *non-Cygwin* application, you should be able to do the 
following:

  #include <windows.h>
  #include <stdio.h>
  #include <sys/types.h>

  static int
  conv_to_win32_path (const char *cygwin_path, char *win32_path)
  {
    HINSTANCE handle;
    FARPROC func;
    typedef int (* functype) (const char *, char *);

    handle = LoadLibrary ("shim.dll");
    if (! handle)
      return 1;
    
    /* Note the @8. You can of course "alias" it to be without the <n>
       when building the DLL.  */
    func = (functype) GetProcAddress ("conv_to_win32_path AT 8");
    if (! func)
      return 2;

    return (* func) (cygwin_path, win32_path);
  }
    
  int
  main ()
  {
    const char *cygwin_path = "/usr/local";
    char buf[MAX_PATH];

    conv_to_win32_path (cygwin_path, buf);
    return 0;
  }


This is completely untested, so please blame me if this hoses your machine 
and reformats your hard drive ;-)

Regards,
Mumit



--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com