Excel dlls and file locking

Excel dlls and file locking

[Fifer, Eric]

I have created a dll that is called from Excel and it works fine,
however all files that it opens are locked.

I think what is happening is that the host_dependent.shared parameter
to CreateFileA is 0 (in fhandler.cc fhandler_base::open) because it is
not being initialized by the cygwin_noncygwin_dll_entry point.

The call stack is something like cygwin_noncygwin_dll_entry ->
cygwin_attach_noncygwin_dll -> dll_noncygwin_dllcrt0 ->
dll_dllcrt0_1 (in dll_init.c)

And in comparison to dll_crt0_1 in dcrt0.cc there is NO call
to host_dependent.init()

I've also been trying to turn strace on in the dll with no luck,
setting the environment with STRACE=0x10 or CYGWIN=strace=0x10 does
nothing inside the dll.

I also fiddled directly with cygwin_getshared(), but this didn't
work either. 

I'm using the original b20.1 cygwin1.dll.

Is there anyway to work around this without building a new cygwin1.dll?

Thanks in advance.

Eric Fifer

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Excel dlls and file locking

[Mumit Khan]

On Thu, 24 Jun 1999, Fifer, Eric wrote:

> 
> I have created a dll that is called from Excel and it works fine,
> however all files that it opens are locked.
> 
> I think what is happening is that the host_dependent.shared parameter
> to CreateFileA is 0 (in fhandler.cc fhandler_base::open) because it is
> not being initialized by the cygwin_noncygwin_dll_entry point.
> 
> The call stack is something like cygwin_noncygwin_dll_entry ->
> cygwin_attach_noncygwin_dll -> dll_noncygwin_dllcrt0 ->
> dll_dllcrt0_1 (in dll_init.c)
> 
> And in comparison to dll_crt0_1 in dcrt0.cc there is NO call
> to host_dependent.init()

Thanks for the analysis. I nor anyone else has worked on the noncygwin
hack since b20.1, so I doubt if it's fixed. If you want to take a crack
at the fix, I'll be happy to take a look and test.

Regards,
Mumit



--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Excel dlls and file locking

[Fifer, Eric]

I have created a dll that is called from Excel and it works fine,
however all files that it opens are locked.

I think what is happening is that the host_dependent.shared parameter
to CreateFileA is 0 (in fhandler.cc fhandler_base::open) because it is
not being initialized by the cygwin_noncygwin_dll_entry point.

The call stack is something like cygwin_noncygwin_dll_entry ->
cygwin_attach_noncygwin_dll -> dll_noncygwin_dllcrt0 ->
dll_dllcrt0_1 (in dll_init.c)

And in comparison to dll_crt0_1 in dcrt0.cc there is NO call
to host_dependent.init()

I've also been trying to turn strace on in the dll with no luck,
setting the environment with STRACE=0x10 or CYGWIN=strace=0x10 does
nothing inside the dll.

I also fiddled directly with cygwin_getshared(), but this didn't
work either. 

I'm using the original b20.1 cygwin1.dll.

Is there anyway to work around this without building a new cygwin1.dll?

Thanks in advance.

Eric Fifer

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Excel dlls and file locking

[Mumit Khan]

On Thu, 24 Jun 1999, Fifer, Eric wrote:

> 
> I have created a dll that is called from Excel and it works fine,
> however all files that it opens are locked.
> 
> I think what is happening is that the host_dependent.shared parameter
> to CreateFileA is 0 (in fhandler.cc fhandler_base::open) because it is
> not being initialized by the cygwin_noncygwin_dll_entry point.
> 
> The call stack is something like cygwin_noncygwin_dll_entry ->
> cygwin_attach_noncygwin_dll -> dll_noncygwin_dllcrt0 ->
> dll_dllcrt0_1 (in dll_init.c)
> 
> And in comparison to dll_crt0_1 in dcrt0.cc there is NO call
> to host_dependent.init()

Thanks for the analysis. I nor anyone else has worked on the noncygwin
hack since b20.1, so I doubt if it's fixed. If you want to take a crack
at the fix, I'll be happy to take a look and test.

Regards,
Mumit



--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

RE: Excel dlls and file locking

[Fifer, Eric]

>I nor anyone else has worked on the noncygwin
>hack since b20.1, so I doubt if it's fixed. If you want to take a crack
>at the fix, I'll be happy to take a look and test.

I might take you up on that, but I don't have the time right now.
I was just hoping for a quick fix.  Regardless, thanks for confirming
my suspicions.

The reason I stumbled across it, is that the dll I've been coding up is an
interface to perl (I call it VBPerl) which is tightly bundled with
Win32::OLE.
It lets me call perl directly from Excel and in the perl code you can freely
access the Excel object hierarchy via the COM interface provided by
Win32::OLE
(just like VB).  The perl debugger even works.  The last thing I need to do
is
send off the patches to the Win32::OLE maintainer.

Anyways, we have cygwin and perl installed on a network drive and when
you do a stat in cygwin it actually opens the file using the
host_dependent.shared
setting.  Unfortunately, if anyone else has the file open the stat then
fails
because of the exclusive lock request.  Fortunately, perl doesn't keep stuff
open that
long, but when you have a XSUB dll loaded into a program anywhere on the
network
a cygwin stat will fail.  For now, in DynaLoader.pm I removed the stat and
just load
the dll, which should work as long everything is installed correctly.  Now,
I
should only see occassional failures if people are loading things up around
the
same time :-(

Thanks.

Eric Fifer


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

RE: Excel dlls and file locking

[Fifer, Eric]

>I nor anyone else has worked on the noncygwin
>hack since b20.1, so I doubt if it's fixed. If you want to take a crack
>at the fix, I'll be happy to take a look and test.

I might take you up on that, but I don't have the time right now.
I was just hoping for a quick fix.  Regardless, thanks for confirming
my suspicions.

The reason I stumbled across it, is that the dll I've been coding up is an
interface to perl (I call it VBPerl) which is tightly bundled with
Win32::OLE.
It lets me call perl directly from Excel and in the perl code you can freely
access the Excel object hierarchy via the COM interface provided by
Win32::OLE
(just like VB).  The perl debugger even works.  The last thing I need to do
is
send off the patches to the Win32::OLE maintainer.

Anyways, we have cygwin and perl installed on a network drive and when
you do a stat in cygwin it actually opens the file using the
host_dependent.shared
setting.  Unfortunately, if anyone else has the file open the stat then
fails
because of the exclusive lock request.  Fortunately, perl doesn't keep stuff
open that
long, but when you have a XSUB dll loaded into a program anywhere on the
network
a cygwin stat will fail.  For now, in DynaLoader.pm I removed the stat and
just load
the dll, which should work as long everything is installed correctly.  Now,
I
should only see occassional failures if people are loading things up around
the
same time :-(

Thanks.

Eric Fifer


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com