Size and dependencies of bit.dll (LuaForWindows)

classic Classic list List threaded Threaded
24 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Size and dependencies of bit.dll (LuaForWindows)

"J.Jørgen von Bargen"
All the time I wondered about the dependencies and size of bit.dll.

Encouraged by my work on a gpx decompression lib I twiddled
around with LuaBitOp-1.0.1 and did the following patch



bit.c
180,192d177
+ #ifdef _WIN32
+ #pragma comment(linker, "/OPT:NOWIN98")
+
+ #include <windows.h>
+ BOOL WINAPI DllMain(
+    HINSTANCE hinstDLL,
+    DWORD fdwReason,
+    LPVOID lpvReserved
+ )
+ {
+ return TRUE;
+ }
+ #endif


msvcbuild.bat
21c20
- %MYLINK% /DLL /export:luaopen_bit /out:bit.dll bit.obj %LUA_LIB%
+ %MYLINK% /DLL /entry:"DllMain" /export:luaopen_bit /out:bit.dll
  bit.obj %LUA_LIB%

And WOW, this reduced bit.dll from 20480 to 4096 bytes and completly
removed the dependency from any msvcrt*.dll. I did not see any bad
side effects yet, the msvctest.bat runs flawlessly.

Do you have any cons for this approach?

Regards Jørgen




Reply | Threaded
Open this post in threaded view
|

Re: Size and dependencies of bit.dll (LuaForWindows)

Rob Kendrick-2
On Mon, Sep 27, 2010 at 09:26:25AM +0000, J.Jørgen von Bargen wrote:
> bit.c
> 180,192d177
> + #ifdef _WIN32
> + #pragma comment(linker, "/OPT:NOWIN98")

This will no doubt annoy people on Windows who do not use Microsoft's
toolchain.

> And WOW, this reduced bit.dll from 20480 to 4096 bytes

But we've wasted more than is ever likely to be saved by talking about
it :)

B.

Reply | Threaded
Open this post in threaded view
|

Re: Size and dependencies of bit.dll (LuaForWindows)

"J.Jørgen von Bargen"
Rob Kendrick <rjek <at> rjek.com> writes:

>
> On Mon, Sep 27, 2010 at 09:26:25AM +0000, J.Jørgen von Bargen wrote:
> > bit.c
> > 180,192d177
> > + #ifdef _WIN32
> > + #pragma comment(linker, "/OPT:NOWIN98")
>
> This will no doubt annoy people on Windows who do not use Microsoft's
> toolchain.

Well, I assume they would not use MSVCBUILD.BAT and have no _WIN32 :-)
else change to #if defined(_WIN32) && defined(_MSC_VER)

> > And WOW, this reduced bit.dll from 20480 to 4096 bytes
> But we've wasted more than is ever likely to be saved by talking about
> it :)

Unneeded DLLs dependencies are a source of pain, so I try to avoid them
where ever possible. And specialy the MSVC[mpr](71|80|90).dll gives headache
after a short and for a long time :-/

Regards




Reply | Threaded
Open this post in threaded view
|

Re: Size and dependencies of bit.dll (LuaForWindows)

steve donovan
2010/9/27 J.Jørgen von Bargen <[hidden email]>:
> Unneeded DLLs dependencies are a source of pain, so I try to avoid them
> where ever possible. And specialy the MSVC[mpr](71|80|90).dll gives headache
> after a short and for a long time :-/

That's completely true. Just look at the long list of executables for
Windows on LuaBinaries.

Personally, mingw saves the day though I believe that it is still not
doing Win64 builds.

steve d.

Reply | Threaded
Open this post in threaded view
|

Re: Size and dependencies of bit.dll (LuaForWindows)

Rob Kendrick-2
In reply to this post by "J.Jørgen von Bargen"
On Mon, Sep 27, 2010 at 10:03:23AM +0000, J.Jørgen von Bargen wrote:

> Rob Kendrick <rjek <at> rjek.com> writes:
>
> >
> > On Mon, Sep 27, 2010 at 09:26:25AM +0000, J.Jørgen von Bargen wrote:
> > > bit.c
> > > 180,192d177
> > > + #ifdef _WIN32
> > > + #pragma comment(linker, "/OPT:NOWIN98")
> >
> > This will no doubt annoy people on Windows who do not use Microsoft's
> > toolchain.
>
> Well, I assume they would not use MSVCBUILD.BAT and have no _WIN32 :-)
> else change to #if defined(_WIN32) && defined(_MSC_VER)

You assume wrongly:

rjek@trite:~$ cat test.c
#ifdef _WIN32
#error Argh, Windows!
#endif

rjek@trite:~$ i586-mingw32msvc-gcc -c test.c
test.c:2:2: error: #error Argh, Windows!

B.

Reply | Threaded
Open this post in threaded view
|

Re: Size and dependencies of bit.dll (LuaForWindows)

Shmuel Zeigerman
In reply to this post by steve donovan
steve donovan wrote:
> Personally, mingw saves the day though I believe that it is still not
> doing Win64 builds.

TDM-GCC [1] states:
> It can create 32-bit OR 64-bit binaries, for any version of Windows since Windows 95.

[1] http://tdm-gcc.tdragon.net/

--
Shmuel

Reply | Threaded
Open this post in threaded view
|

Re: Size and dependencies of bit.dll (LuaForWindows)

steve donovan
On Mon, Sep 27, 2010 at 12:51 PM, Shmuel Zeigerman <[hidden email]> wrote:
> TDM-GCC [1] states:
>>
>> It can create 32-bit OR 64-bit binaries, for any version of Windows since
>> Windows 95.

Glad to hear this - my favourite mingw distribution.  There is no
longer any performance difference that might make the MS tools have an
edge.

Of course, people work with Lua and Visual Studio. But then they are
surely capable of using binaries from LuaBinaries or building the
libraries themselves.

LfW is intended mostly for users of Lua, so there is no longer any
compelling reason to use the MS tools for it.

steve d.

Reply | Threaded
Open this post in threaded view
|

Re: Size and dependencies of bit.dll (LuaForWindows)

"J.Jørgen von Bargen"
steve donovan <steve.j.donovan <at> gmail.com> writes:

> Of course, people work with Lua and Visual Studio. But then they are
> surely capable of using binaries from LuaBinaries or building the
> libraries themselves.
>
> LfW is intended mostly for users of Lua, so there is no longer any
> compelling reason to use the MS tools for it.

World is not /so/ easy. I'm developing lua-scripts (with LuaForWindows),
which are to be used (in compiled form) by a windows application, which
(for my knowledge) is build with VisualStudio2008. (and where I have no
source)

Problems arise, when I require DLLs, which are copied from LuaForWindows
into the target application space. The Call-Tree:

[Foreign-Windows-Application-with-buildin-lua]
   load-and-calls-->
     [my-lua-script.luac]
       requires-->
         [some-lua-dll-from-LfW]
           has-dependency-->
             [some-other-dll-from-LfW]
               has-dependency-->
                 [some-microsoft-dll]

This is indended to work also, when only the application is installed
(including my script and required DLLs), but without installing LfW.
Specially I need iup to generate some settings dialogs for my scripts.

I'm not shure, what would happen, if the LfW-DLLs were build with mingw.

Regards

Another problem is, that "required" takes a look at package.cpath for loading
the DLLs, but "has-dependency" is resolved by Windows itself, not taking
care of package.cpath. I've still looking for a proper solution for this.



Reply | Threaded
Open this post in threaded view
|

Re: Size and dependencies of bit.dll (LuaForWindows)

steve donovan
2010/9/27 J.Jørgen von Bargen <[hidden email]>:
> [Foreign-Windows-Application-with-buildin-lua]
>   load-and-calls-->
>     [my-lua-script.luac]
>       requires-->
>         [some-lua-dll-from-LfW]
>           has-dependency-->
>             [some-other-dll-from-LfW]
>               has-dependency-->
>                 [some-microsoft-dll]

LfW uses MSVC 2005 runtime, so problems are likely to emerge.  The
DLLs would need to be rebuilt AFAIK with 2008 (I would like to be
corrected on this)

> Another problem is, that "required" takes a look at package.cpath for loading
> the DLLs, but "has-dependency" is resolved by Windows itself, not taking
> care of package.cpath. I've still looking for a proper solution for this.

That's why LfW adds %LUA%\clibs to PATH, so that dependencies will be
found by Windows. This is not exactly a pretty solution ;)

steve d.

Reply | Threaded
Open this post in threaded view
|

Re: Size and dependencies of bit.dll (LuaForWindows)

steve donovan
In reply to this post by "J.Jørgen von Bargen"
2010/9/27 J.Jørgen von Bargen <[hidden email]>:
> I'm not shure, what would happen, if the LfW-DLLs were build with mingw.

Probably still have trouble ;)

One of the things-we-would-like-to-do for LfW is a proper build
system.  The best candidate so far is LuaDist, which uses CMake. That
should build on pretty much anything, with the compiler of choice.

steve d.

Reply | Threaded
Open this post in threaded view
|

Re: Size and dependencies of bit.dll (LuaForWindows)

"J.Jørgen von Bargen"
In reply to this post by steve donovan

> 2010/9/27 J.Jørgen von Bargen <jjvb.primus <at> gmx.de>:
> > Another problem is, that "required" takes a look at package.cpath for
> > loading the DLLs, but "has-dependency" is resolved by Windows itself,
> > not taking care of package.cpath. I've still looking for a proper
> > solution for this.

steve donovan <steve.j.donovan <at> gmail.com> writes:

> That's why LfW adds %LUA%\clibs to PATH, so that dependencies will be
> found by Windows. This is not exactly a pretty solution ;)

A nice transliteration for a dirty thing :-) And one of the reasons,
I first became aware of the problems on delivery to beta-testers
(which of course didn't have LfW installed)

It's always a mess, I you have (same or different) multiple instances
of DLLs distributed on your system but need to load a specific on in
a given application. I've contacted the author to prepend his
application clibs path to his PATH environment on application startup.
I will report results, when he did so.

Regards and thanks for your input Jørgen



Reply | Threaded
Open this post in threaded view
|

Re: Size and dependencies of bit.dll (LuaForWindows)

Edgar Toernig
In reply to this post by steve donovan
steve donovan wrote:
>
> > I'm not shure, what would happen, if the LfW-DLLs were build with mingw.
>
> Probably still have trouble ;)

Care to elaborate?

My experience (with C code) is that once you get the app compiled
with mingw you have absolutely no problems any more.

IMO, any DLL which requires any of the visual-c runtimes and is
supposed to be used by foreign apps is *broken* period.

If you don't want to use mingw, take the WDK - it creates DLLs and
EXEs that link against plain msvcrt.dll.  No "Visual" gadgetry
though and all of MS's command line tools seem to be in alpha-state.

And if you really want to use VS: I think there are tutorials on how
to create VS-apps that link against msvcrt.dll and need no redistrib-
utables.

But honestly: if you have any C-development background on Unix
you'll love the mingw/msys combo.  A plain compiler which generates
native windows apps.  No glue-layer or anything.  You get a working
(g)cc, (gnu)make, (ba)sh, shell-utils, bin-utils, windres (for the
resource stuff), vi(m), ...  git works fine, too.

I think, without ming/msys I would have quit my job ;-)

And don't mistake mingw with cygwin.  Cygwin provides a Unix environ-
ment for Unix-apps on windows with a big DLL and a very complicated
emulation-layer.  It's not really meant to produce stand-alone Windows
executables.

Ciao, ET.

Reply | Threaded
Open this post in threaded view
|

Re: Size and dependencies of bit.dll (LuaForWindows)

Rob Kendrick-2
On Mon, Sep 27, 2010 at 09:46:46PM +0200, E. Toernig wrote:
>
> But honestly: if you have any C-development background on Unix
> you'll love the mingw/msys combo.  A plain compiler which generates
> native windows apps.  No glue-layer or anything.  You get a working
> (g)cc, (gnu)make, (ba)sh, shell-utils, bin-utils, windres (for the
> resource stuff), vi(m), ...  git works fine, too.
>
> I think, without ming/msys I would have quit my job ;-)

We cross-compile all our Windows software using MinGW from Linux.  If I
couldn't do this and I was forced to put up with Windows build tools, I
would have gone on a murderous rampage by now, and *then* quit my job.

B.

Reply | Threaded
Open this post in threaded view
|

Re: Size and dependencies of bit.dll (LuaForWindows)

Drake Wilson-3
In reply to this post by Edgar Toernig
Quoth "E. Toernig" <[hidden email]>, on 2010-09-27 21:46:46 +0200:
> If you don't want to use mingw, take the WDK - it creates DLLs and
> EXEs that link against plain msvcrt.dll.  No "Visual" gadgetry
> though and all of MS's command line tools seem to be in alpha-state.
>
> And if you really want to use VS: I think there are tutorials on how
> to create VS-apps that link against msvcrt.dll and need no redistrib-
> utables.

I'm curious how this interacts with the official platform stance
apparently being that this is a broken thing to be doing for
general-purpose applications and that you're playing with fire trying
to link against MSVCRT directly.

See http://msdn.microsoft.com/en-us/library/abx4dbyh%28VS.80%29.aspx:
| What is the difference between msvcrt.dll and msvcr80.dll?
|
| The msvcrt.dll is now a "known DLL," meaning that it is a system
| component owned and built by Windows. It is intended for future use
| only by system-level components.

Or for instance:
  http://www.dotnetmonster.com/Uwe/Forum.aspx/vs-net-general/1259/msvcr70-dl-msvcrt-dll
  http://stackoverflow.com/questions/190059/building-windows-c-libraries-without-a-runtime

(Yes, this does imply that MinGW linking against MSVCRT by default
seems broken to me, though not necessarily in an easily rectifiable
way.  I would tend to think that the theoretically-correct approach
would be along the lines of an extra libre CRT for Windows of some
kind, but I'm insufficiently experienced with Windows to be sure of
that.)

   ---> Drake Wilson

Reply | Threaded
Open this post in threaded view
|

Re: Size and dependencies of bit.dll (LuaForWindows)

steve donovan
On Tue, Sep 28, 2010 at 2:19 AM, Drake Wilson <[hidden email]> wrote:
> (Yes, this does imply that MinGW linking against MSVCRT by default
> seems broken to me, though not necessarily in an easily rectifiable
> way.  I would tend to think that the theoretically-correct approach
> would be along the lines of an extra libre CRT for Windows of some
> kind, but I'm insufficiently experienced with Windows to be sure of
> that.)

It's clearly an idea that's in the air, as a quick Google search
indicates, but it would be a big job.  And remember that msvcrt.dll
also provides basic C++ support, which is tangled up with the MS
implementation.

(There would also be a temptation to fix 'broken' things ;))

steve d.

PS. Yes, I hear this, that MS does not recommend msvcrt.dll, but _in
practice_ things seem to work ok across Windows versions.  (They do
want you to use their tools, after all)

Reply | Threaded
Open this post in threaded view
|

Re: Size and dependencies of bit.dll (LuaForWindows)

steve donovan
In reply to this post by Edgar Toernig
On Mon, Sep 27, 2010 at 9:46 PM, E. Toernig <[hidden email]> wrote:
> My experience (with C code) is that once you get the app compiled
> with mingw you have absolutely no problems any more.

Fine, if everything is built against it. But the original situation is
where there is a (unmodifiable) program linked against another
runtime. There are some scenarios which will cause trouble; something
allocated in one runtime freed in another, and so forth. You can be
careful, but you can't guarantee that all extensions will be careful.

A good summary is on the Wiki (although a bit disorganized):

http://lua-users.org/wiki/BuildingModules

> IMO, any DLL which requires any of the visual-c runtimes and is
> supposed to be used by foreign apps is *broken* period.

Well it's just the way they do it ;)  I don't like it personally, and
find that Visual Studio gives me a headache.  There are two obvious
jokes (1) the word 'Visual' and (2) 'makes life easier for
programmers'.

The mingw tools are just great, no fuss, works like one expects - I've
been a convert for a long time!

steve d.

PS. This is important stuff, because Windows has become a troublesome
target for software development. However, one can't ignore 80% of the
world's desktops.

Reply | Threaded
Open this post in threaded view
|

Re: Size and dependencies of bit.dll (LuaForWindows)

steve donovan
In reply to this post by steve donovan
On Tue, Sep 28, 2010 at 8:59 AM, steve donovan
<[hidden email]> wrote:
> It's clearly an idea that's in the air, as a quick Google search
> indicates, but it would be a big job.

And naturally some people have gone ahead and hacked away:

http://sourceforge.net/projects/wcrt/

http://www.codeproject.com/KB/library/tlibc.aspx

This should appeal to Jørgen because he showed us such a small DLL -
these are guys who like 4K executables ;)

But even if there was a new libre CRT, one can't relink something
that's already linked, which was the original problem.

steve d.

Reply | Threaded
Open this post in threaded view
|

Re: Size and dependencies of bit.dll (LuaForWindows)

Edgar Toernig
In reply to this post by Drake Wilson-3
Drake Wilson wrote:
>
> I'm curious how this interacts with the official platform stance
> apparently being that this is a broken thing to be doing for
> general-purpose applications and that you're playing with fire trying
> to link against MSVCRT directly.

They are playing games.  Microsoft doesn't really want independant
software developers (they only hurt their business), they want to
sell a product: Visual Studio.  And the crt is the doc-format of the
compiler: every release a new version so that when one developer up-
dates all other have to update, too.

Regarding the "playing with fire trying to link against MSVCRT directly":
This advice is for the Visual Studio compiler - afaik it needs some
compiler dependent stuff (i.e. exception handling etc.) from its CRTs.

All EXEs and DLLs from Microsoft link against it (and nearly none
against one of the MSVCRxx.DLLs!).  If you are linking against one of
the other DLLs (GDI32, COMCTL32, WINSPOOL, ...) you are already linking
against MSCVRT.DLL anyway.  You would use the same runtime they are
using.  Less potential for problems.  And the documentation of MSVCRT is
at the same level as that for GDI32, COMCTL32, ...  So why not use it?

The mingw compiled Lua will run on anything from W2k (I guess even Win98)
to Win7.  Try that with VS2010 ...

Ciao, ET.

Reply | Threaded
Open this post in threaded view
|

Re: Size and dependencies of bit.dll (LuaForWindows)

Javier Guerra Giraldez
On Tue, Sep 28, 2010 at 5:31 PM, E. Toernig <[hidden email]> wrote:
> They are playing games.  Microsoft doesn't really want independant
> software developers (they only hurt their business), they want to
> sell a product: Visual Studio.

i doubt they make any money on developer tools.   i think the strategy
is to make development and testing dead easy on single machines, but
deployment a lot harder.

the difficulty of deployment doesn't affect the choice of tools
because: a) it only hurts waaay after you've commited a lot of work to
the tools, so migration is out of the question. and b) it's done by
other 'less important' people.

why do they want to make deployment harder? i'm not sure; but i guess
it's to help with planned obsolecense. since developers always have
the latest from redmond (in many cases it's free of charge); support
is easy only if the user has the latest OS too.

just check all the cheap and gratis software for windows; only the
really good support old versions.  everybody else helps to make old
platforms less and less usable.

--
Javier

Reply | Threaded
Open this post in threaded view
|

Re: Size and dependencies of bit.dll (LuaForWindows)

Javier Guerra Giraldez
In reply to this post by Edgar Toernig
On Tue, Sep 28, 2010 at 5:31 PM, E. Toernig <[hidden email]> wrote:
> They are playing games.  Microsoft doesn't really want independant
> software developers (they only hurt their business), they want to
> sell a product: Visual Studio.

i doubt they make any money on developer tools.   i think the strategy
is to make development and testing dead easy on single machines, but
deployment a lot harder.

the difficulty of deployment doesn't affect the choice of tools
because: a) it only hurts waaay after you've commited a lot of work to
the tools, so migration is out of the question. and b) it's done by
other 'less important' people.

why do they want to make deployment harder? i'm not sure; but i guess
it's to help with planned obsolecense. since developers always have
the latest from redmond (in many cases it's free of charge); support
is easy only if the user has the latest OS too.

just check all the cheap and gratis software for windows; only the
really good support old versions.  everybody else helps to make old
platforms less and less usable.

--
Javier

12