www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - std.recls - FTP raises linkage issue

reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
Hi

I want to canvas opinion regarding the forthcoming updates to recls, which will
be reflected in D very soon.

Simply put, recls has had two externally visible enhancements:

1. One can now specify multi-part filters, e.g. "*.cpp;*.d;makefile*, which is
far more convenient (and efficient) than conducting N separate searches. I'm
assuming this will be welcomed by all, but I'm open to being surprised. <G>

2. recls can now enumerate FTP hierarches (currently Win32 only), as well as the
local file-system. Naturally, this is a very nice thing, and I'm hoping people
will think it's as cool as I do. I intend to write a very succinct sample
program
for Phobos that does a recursive attribute/size/date diff between a local
directory and an FTP site. As well as a nice example of the succinctness of D's
power, this tool'll simplify my life enormously. ;)

But here's the rub. There are two choices for the implementation (on Win32):

A. Build it all, and require that users of recls/phobos link to wininet.lib. My
instincts rail against such things, but then pretty much any modern non-trivial
Win32 app links in WinInet, so maybe it's a non-issue after all.

B. Provide a separate D component for FTP enumeration. Since D requires that
modules cannot be multifile, this could not be in the std.recls namespace, and,
IMO, would be too much hard work for the implementors and users alike.

So, it seems to me that we have to link Phobos to WinInet. Either that, or the D
community states that they don't want FTP enumeration (and we build Phobos with
RECLS_NO_FTP_API defined).

Actually, there's a third choice. We can provide a static WinInet stub library,
which only loads and invokes the real WinInet.DLL functions when required. When
not, it'll occupy only a few byes of one's exe. Of course, if Walter would
implement delay loading linking for DMC++ this would be non-issue. (Walter: if
that's already in, please require me to eat my shorts, but don't forget to
publicise this facility more thoroughly.)

I'd be interested to here any/all thoughts.


Matthew Wilson

Author: "Imperfect C++", Addison-Wesley, 2004
    (http://www.imperfectcplusplus.com)
Contributing editor, C/C++ Users Journal
    (http://www.synesis.com.au/articles.html#columns)
STLSoft moderator
    (http://www.stlsoft.org)

-------------------------------------------------------------------------------

"So far, C++ is the best language I've discovered to say what I want to say" -- 
Alex Stepanov

-------------------------------------------------------------------------------
Jun 01 2004
next sibling parent reply Regan Heath <regan netwin.co.nz> writes:
On Wed, 2 Jun 2004 13:43:24 +1000, Matthew <matthew.hat stlsoft.dot.org> 
wrote:
 I want to canvas opinion regarding the forthcoming updates to recls, 
 which will be reflected in D very soon.

 Simply put, recls has had two externally visible enhancements:

 1. One can now specify multi-part filters, e.g. "*.cpp;*.d;makefile*, 
 which is
 far more convenient (and efficient) than conducting N separate searches. 
 I'm
 assuming this will be welcomed by all, but I'm open to being surprised. 
 <G>

Sounds very natty.
 2. recls can now enumerate FTP hierarches (currently Win32 only), as 
 well as the
 local file-system. Naturally, this is a very nice thing, and I'm hoping 
 people
 will think it's as cool as I do. I intend to write a very succinct 
 sample program
 for Phobos that does a recursive attribute/size/date diff between a local
 directory and an FTP site. As well as a nice example of the succinctness 
 of D's
 power, this tool'll simplify my life enormously. ;)

 But here's the rub. There are two choices for the implementation (on 
 Win32):

 A. Build it all, and require that users of recls/phobos link to 
 wininet.lib. My
 instincts rail against such things, but then pretty much any modern 
 non-trivial
 Win32 app links in WinInet, so maybe it's a non-issue after all.

The key word being "non-trivial". Would this force a trivial program to link against it unnecessarily?
 B. Provide a separate D component for FTP enumeration. Since D requires 
 that
 modules cannot be multifile

Walter may be thinking about changing this... Walter?
 , this could not be in the std.recls namespace, and,
 IMO, would be too much hard work for the implementors and users alike.

 So, it seems to me that we have to link Phobos to WinInet. Either that, 
 or the D
 community states that they don't want FTP enumeration (and we build 
 Phobos with
 RECLS_NO_FTP_API defined).

I think we want to be able to choose to have FTP enumeration, and if we choose not to, we should not have to link against WinInet. We should be able to achieve that, if not, why not.
 Actually, there's a third choice. We can provide a static WinInet stub 
 library,
 which only loads and invokes the real WinInet.DLL functions when 
 required. When
 not, it'll occupy only a few byes of one's exe. Of course, if Walter 
 would
 implement delay loading linking for DMC++ this would be non-issue. 
 (Walter: if
 that's already in, please require me to eat my shorts, but don't forget 
 to
 publicise this facility more thoroughly.)

 I'd be interested to here any/all thoughts.


 Matthew Wilson

 Author: "Imperfect C++", Addison-Wesley, 2004
     (http://www.imperfectcplusplus.com)
 Contributing editor, C/C++ Users Journal
     (http://www.synesis.com.au/articles.html#columns)
 STLSoft moderator
     (http://www.stlsoft.org)

 -------------------------------------------------------------------------------

 "So far, C++ is the best language I've discovered to say what I want to 
 say" --
 Alex Stepanov

 -------------------------------------------------------------------------------

-- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Jun 01 2004
parent "Matthew" <matthew.hat stlsoft.dot.org> writes:
"Regan Heath" <regan netwin.co.nz> wrote in message
news:opr8x9s1wf5a2sq9 digitalmars.com...
 On Wed, 2 Jun 2004 13:43:24 +1000, Matthew <matthew.hat stlsoft.dot.org>
 wrote:
 I want to canvas opinion regarding the forthcoming updates to recls,
 which will be reflected in D very soon.

 Simply put, recls has had two externally visible enhancements:

 1. One can now specify multi-part filters, e.g. "*.cpp;*.d;makefile*,
 which is
 far more convenient (and efficient) than conducting N separate searches.
 I'm
 assuming this will be welcomed by all, but I'm open to being surprised.
 <G>

Sounds very natty.
 2. recls can now enumerate FTP hierarches (currently Win32 only), as
 well as the
 local file-system. Naturally, this is a very nice thing, and I'm hoping
 people
 will think it's as cool as I do. I intend to write a very succinct
 sample program
 for Phobos that does a recursive attribute/size/date diff between a local
 directory and an FTP site. As well as a nice example of the succinctness
 of D's
 power, this tool'll simplify my life enormously. ;)

 But here's the rub. There are two choices for the implementation (on
 Win32):

 A. Build it all, and require that users of recls/phobos link to
 wininet.lib. My
 instincts rail against such things, but then pretty much any modern
 non-trivial
 Win32 app links in WinInet, so maybe it's a non-issue after all.

The key word being "non-trivial". Would this force a trivial program to link against it unnecessarily?
 B. Provide a separate D component for FTP enumeration. Since D requires
 that
 modules cannot be multifile

Walter may be thinking about changing this... Walter?
 , this could not be in the std.recls namespace, and,
 IMO, would be too much hard work for the implementors and users alike.

 So, it seems to me that we have to link Phobos to WinInet. Either that,
 or the D
 community states that they don't want FTP enumeration (and we build
 Phobos with
 RECLS_NO_FTP_API defined).

I think we want to be able to choose to have FTP enumeration, and if we choose not to, we should not have to link against WinInet. We should be able to achieve that, if not, why not.
 Actually, there's a third choice. We can provide a static WinInet stub
 library,
 which only loads and invokes the real WinInet.DLL functions when
 required. When
 not, it'll occupy only a few byes of one's exe. Of course, if Walter
 would
 implement delay loading linking for DMC++ this would be non-issue.
 (Walter: if
 that's already in, please require me to eat my shorts, but don't forget
 to
 publicise this facility more thoroughly.)

 I'd be interested to here any/all thoughts.


The "why not" is that, AFAIK, classes (and I think modules also) are linked atomically. In other words, if I use part of a class, I still have to resolve all the symbols that are used by the rest of that class. Unless we do either the delay-loading (whether the compiler-provided version, or a manual one), then we have no real choice but to require linking to wininet.lib. The alternative is just hideously messy. Maybe it's not an issue though, since it's a system DLL, and we're already binding to most of them in non-trivial programs.
Jun 02 2004
prev sibling parent reply Sean Kelly <sean f4.ca> writes:
In article <c9jid0$930$1 digitaldaemon.com>, Matthew says...
But here's the rub. There are two choices for the implementation (on Win32):

A. Build it all, and require that users of recls/phobos link to wininet.lib. My
instincts rail against such things, but then pretty much any modern non-trivial
Win32 app links in WinInet, so maybe it's a non-issue after all.

Personally, I never link to wininet.lib because it has one major deficiency -- many of the features only work in user mode (ie. they don't work if the application is running as an NT service). I'm not sure that this is worth hand-coding an FTP lib to work around it, but something I wanted to point out. Beyond that, I don't have a problem linking to wininet.lib for my Windows-based D applications. Sean
Jun 02 2004
parent reply Hauke Duden <H.NS.Duden gmx.net> writes:
Sean Kelly wrote:
But here's the rub. There are two choices for the implementation (on Win32):

A. Build it all, and require that users of recls/phobos link to wininet.lib. My
instincts rail against such things, but then pretty much any modern non-trivial
Win32 app links in WinInet, so maybe it's a non-issue after all.

Personally, I never link to wininet.lib because it has one major deficiency -- many of the features only work in user mode (ie. they don't work if the application is running as an NT service). I'm not sure that this is worth hand-coding an FTP lib to work around it, but something I wanted to point out.

The other major deficiency being, of course, that it isn't available on all Windows versions. Hauke
Jun 02 2004
parent reply "Walter" <newshound digitalmars.com> writes:
"Hauke Duden" <H.NS.Duden gmx.net> wrote in message
news:c9l14k$2e7m$1 digitaldaemon.com...
 Sean Kelly wrote:
But here's the rub. There are two choices for the implementation (on



A. Build it all, and require that users of recls/phobos link to



instincts rail against such things, but then pretty much any modern



Win32 app links in WinInet, so maybe it's a non-issue after all.

Personally, I never link to wininet.lib because it has one major


 many of the features only work in user mode (ie. they don't work if the
 application is running as an NT service).  I'm not sure that this is


 hand-coding an FTP lib to work around it, but something I wanted to


 The other major deficiency being, of course, that it isn't available on
 all Windows versions.

In that case, it should do a runtime check & load rather than a static link.
Jun 04 2004
parent "Matthew" <matthew.hat stlsoft.dot.org> writes:
"Walter" <newshound digitalmars.com> wrote in message
news:c9p94o$2kb6$2 digitaldaemon.com...
 "Hauke Duden" <H.NS.Duden gmx.net> wrote in message
 news:c9l14k$2e7m$1 digitaldaemon.com...
 Sean Kelly wrote:
But here's the rub. There are two choices for the implementation (on



A. Build it all, and require that users of recls/phobos link to



instincts rail against such things, but then pretty much any modern



Win32 app links in WinInet, so maybe it's a non-issue after all.

Personally, I never link to wininet.lib because it has one major


 many of the features only work in user mode (ie. they don't work if the
 application is running as an NT service).  I'm not sure that this is


 hand-coding an FTP lib to work around it, but something I wanted to


 The other major deficiency being, of course, that it isn't available on
 all Windows versions.

In that case, it should do a runtime check & load rather than a static link.

Ok, I'll work on that. It'll require some hokey #define / #include magic, but that's one of the things C/C++ are good at. He he ... However, there is one problem. What do we do about when people want to link to WinInet within their own work? Can anyone envisage problems with WinInet doing initialisation differently when implicitly vs explicitly loaded.
Jun 05 2004