From: Erik de C. L. <ml...@me...> - 2008-05-26 11:39:39
|
Hi all, Ok, I have some code that I've successfully compiled into a DLL and I'm about to wrap an automated installer around it. The installer will install the following: - The DLL itself. - Developer documentation. - A couple of small demo programs that use the DLL. - Example source code. So where should the installer put the DLL? Lots of programs use this DLL so the obvious solution seems to be C:\System, but that seems to be considered bad form. Any suggestions? Cheers, Erik -- ----------------------------------------------------------------- Erik de Castro Lopo ----------------------------------------------------------------- Linux, the UNIX defragmentation tool. |
From: John B. <joh...@ho...> - 2008-05-26 11:54:58
|
Hello Erik On Mon, 26 May 2008 21:39:31 +1000, Erik de Castro Lopo wrote: > > Hi all, > > Ok, I have some code that I've successfully compiled into a DLL [snip] > > So where should the installer put the DLL? Lots of programs use > this DLL so the obvious solution seems to be C:\System, but that > seems to be considered bad form. > > Any suggestions? > > Cheers, > Erik I think you meant C:\Windows\System32, but you should note the following: 1) The Windows directory is not necessarily called Windows 2) The Windows directory does not have to be on drive C: Your installer must find out the location of the Windows system directory. There is an API function for that (GetsystemDirectory), the MSDN documentation for which says: "This function is provided primarily for compatibility. Applications should store code in the Program Files folder and persistent data in the Application Data folder in the user's profile." I didn't know this until I just read it. Surely they don't mean that shared libraries should no longer be shared? _________________________________________________________________ Make every e-mail and IM count. Join the i’m Initiative from Microsoft. http://im.live.com/Messenger/IM/Join/Default.aspx?source=EML_WL_ MakeCount |
From: Timothy M. <ter...@gm...> - 2008-05-26 12:06:17
|
On Mon, May 26, 2008 at 2:39 PM, Erik de Castro Lopo <ml...@me...<mle%2B...@me...>> wrote: > Hi all, > > Ok, I have some code that I've successfully compiled into a DLL > and I'm about to wrap an automated installer around it. The installer > will install the following: > > - The DLL itself. > - Developer documentation. > - A couple of small demo programs that use the DLL. > - Example source code. > > So where should the installer put the DLL? Lots of programs use > this DLL so the obvious solution seems to be C:\System, but that > seems to be considered bad form. > > Any suggestions? > > You obviously should put it in Program Files, under your company and product name folders, as all the other programs are installed. I think you want to add that install folder to the PATH environment variable. That will make it accessible to any program, no matter were it is installed or where the .dll is installed. Timothy Madden |
From: Erik de C. L. <ml...@me...> - 2008-05-26 12:13:13
|
Timothy Madden wrote: > You obviously should put it in Program Files, under your company and > product name folders, as all the other programs are installed. I think you > want to add that install folder to the PATH environment variable. Surely that solution doesn't scale. What's the maximum length of the PATH string on windows? Erik -- ----------------------------------------------------------------- Erik de Castro Lopo ----------------------------------------------------------------- "The evolution of languages: FORTRAN is a non-typed language. C is a weakly typed language. Ada is a strongly typed language. C++ is a strongly hyped language." -- Ron Sercely |
From: John B. <joh...@ho...> - 2008-05-26 12:30:37
|
Erik de Castro Lopo wrote: > > Timothy Madden wrote: > >> You obviously should put it in Program Files, under your company and >> product name folders, as all the other programs are installed. I think you >> want to add that install folder to the PATH environment variable. > > Surely that solution doesn't scale. What's the maximum length of > the PATH string on windows? > > Erik Google is your friend: http://msmvps.com/blogs/erikr/archive/2007/09/17/maximum-length-of-environment-variables-windows.aspx _________________________________________________________________ E-mail for the greater good. Join the i’m Initiative from Microsoft. http://im.live.com/Messenger/IM/Join/Default.aspx?source=EML_WL_ GreaterGood |
From: Timothy M. <ter...@gm...> - 2008-05-26 12:30:44
|
On Mon, May 26, 2008 at 3:13 PM, Erik de Castro Lopo <ml...@me...<mle%2B...@me...>> wrote: > Timothy Madden wrote: > > > You obviously should put it in Program Files, under your company and > > product name folders, as all the other programs are installed. I think > you > > want to add that install folder to the PATH environment variable. > > Surely that solution doesn't scale. What's the maximum length of > the PATH string on windows? > > I do not know but I never reached it. I have 32 entries in it in about 800 characters Timothy Madden |
From: Earnie B. <ea...@us...> - 2008-05-26 14:14:16
|
Quoting Erik de Castro Lopo <ml...@me...>: > Hi all, > > Ok, I have some code that I've successfully compiled into a DLL > and I'm about to wrap an automated installer around it. The installer > will install the following: > > - The DLL itself. > - Developer documentation. > - A couple of small demo programs that use the DLL. > - Example source code. > > So where should the installer put the DLL? Lots of programs use > this DLL so the obvious solution seems to be C:\System, but that > seems to be considered bad form. > > Any suggestions? I would put the .dll files with the .exe files. The Windows OS will find it in that directory. If this is a development library then you'll also have header files and import libraries as well I assume. So if I have package foo then I would install into foo/bin, foo/lib, foo/include, foo/samples and foo/docs. No other consideration should be made as to where to install and no other consideration for modifying PATH should be done in the install. The developers who use your dll will need to ship it with their executable to make the executable functioning. Earnie |
From: Brian S. <bri...@ho...> - 2008-05-26 14:22:06
|
Thanks for this . ==================================================================== My source forge projectis: To use source codes from Bruce Schneier's book "Applied Cryptography" to compile and run in C++, but there are problems with parsers and binaries. using:eclipse-cpp-europa-winter-win32,e clipsecpppack,MinGW-5.1. 25-5-08 Anyone interested? ======================================================================== Also I have a problem with this prog: /* This program enciphers files using one of Vigenere, Beauford or Variant Beauford ciphers. Note inverses means this code also decrypts - eg encipherment by Vigenere can be deciphered by enciphering with Variant Beauford with the same key. Similarly, Beauford is its own inverse. Input via file or keyboard is of the following format: cipher-type key the message in free format, of any desired length Output will be of the form: theen ciphe redme ssage The cipher type is given by the single letter V (or v) for Vigenere, B (or b) for Beauford and A (or a) for Variant Beauford. Should a different letter be used, a message will be printed to the screen and Vigenere used. Currently the maximum allowed key is 10 characters. Excess is discarded with a warning message sent to the screen. MAXKEYLENGTH can be changed for longer or shorter limits. The key can be *any* ASCII characters, not just alphabetics. Note upper and lower case plaintext are enciphered by converting all to lower case first, with the output solely lower case. Non-alphabetics are discarded, however relatively minor adjustments could be made to allow longer alphabets. The output is given in the traditional 5 letter chunks, but BLOCKLENGTH can be changed to suit personal taste. Similarly, 80 character lines are assumed, but other lengths can be set with LINELENGTH. Two versions of main are given: one for input from the keyboard or from file redirection, the other for input from a file named on the command line. Just uncomment which you wish to use. Note both send output to the screen by default, and allow output redirection to a file (eg ... > outfile) If you wish to specify the output file, the modification is minor. An example for program verification: V orbit An ambassador is an Honest man sent to Lie and Intrigue abroad for the benefit of his Country produces output: oebuu ojtiw cijat bypvx gknig gvobm ccjmt bujvm fzhcx osswt rwpzm vvcmg swjbh tyjav clobk m Note no padding at the end to hide the message length: this is easily added. For instance, the final message letter can be enciphered repeatedly (still with progression through the key to hide the effect) until a block is full. Author: Dr Leisa Condie, December 1992. ph...@ne... Dept of Mathematics, Statistics and Computing Science, University of New England - Armidale, New South Wales, 2351, AUSTRALIA.*/ #define ALPHA 26 /* length of alphabet for modulo */#define MAXKEYLENGTH 10 /* maximum length of the key used */#define BLOCKLENGTH 5 /* for output, how many chars in a block */#define LINELENGTH 80 /* maximum output characters per line */ char key[MAXKEYLENGTH+1]; /* encipherment key: +1 for possible newline */int blockcount = 0; /* counts of chars in printed block */int linechars = 0; /* count of chars printed on current line */int keylength = 0; /* holds actual length of the key */int vigenere=0,beauford=0,varbeau=0; /* cipher type is set to 1 (TRUE) if chosen */FILE *fp; /* set to stdin if interactive, else file */ void getsetup(void){ char ch; /* generic character variable */ char *tmp = key; /* pointer to key array */ /* find cipher type */ ch = getc(fp); if (ch == 'V' || ch == 'v') vigenere =1; else if (ch == 'B'|| ch == 'b') beauford =1; else if (ch == 'A'|| ch == 'a') varbeau =1; else { /* otherwise error, so notify by stderr and use Vigenere */ fprintf(stderr,"V/B/A ciphers only - Vigenere assumed\n"); vigenere =1; } while ((ch=getc(fp)) != '\n'); /* if extraneous input, clear it! */ /* get key - anything after the MAXKEYLENGTH'th char is discarded */ for (keylength=0; keylength < MAXKEYLENGTH; keylength++) if ((key[keylength]= getc(fp)) == '\n') break; if (key[keylength] != '\n'){ while ((ch=getc(fp)) != '\n'); /* if excess key, clear it! */ fprintf(stderr,"Key truncated to %d characters\n",keylength); }} int encipher(int i){ /* Takes argument i - where we are in the key, Returns tmp - the ciphertext equivalent of the input if the input was alphabetic, else the input character unchanged */ char ch; /* character read in */ int tmp; /* for cipher char calculation */ ch = getc(fp); if (ch >= 'A' && ch <= 'Z') { /* convert to lowercase */ ch = ch - 'A' + 'a'; /* don't trust tolower() */ } if (ch >= 'a' && ch <= 'z') { /* encipher */ if (vigenere) tmp = (ch + key[i] - 2*'a') % ALPHA; else if (beauford) tmp = (key[i] - ch) % ALPHA; else tmp = (ch - key[i]) % ALPHA; /* make offset positive and convert to lowercase char */ while (tmp < 0) tmp += ALPHA; tmp += 'a'; } else tmp = ch; /* else return character unchanged */ return(tmp);} void outputcipher(void){ int cipherch, i=0; /* cipher character */ while (!feof(fp)) { /* keep going whilst there is input */ cipherch = encipher(i); /* generate cipher character */ if (cipherch < 'a' || cipherch > 'z') /* invalid char in */ continue; /* ignore code below - restart loop */ /* check we haven't finished key and need to restart it */ if (i == keylength-1) i=0; else i++; /* if a BLOCKLENGTH block is finished print a space */ if (blockcount == BLOCKLENGTH) { /* check whether a newline is needed yet */ if (linechars > LINELENGTH - BLOCKLENGTH) { putchar('\n'); linechars = 0; } else { putchar(' '); linechars++; } blockcount = 0; } /* print enciphered character */ putchar(cipherch); blockcount++; linechars++; } putchar('\n');} /* This version of main is set for input to come from the keyboard either directly or through file redirection: e.g. program < input_file*//*void main(void){ fp = stdin; getsetup(); outputcipher(); }*/ /* This version of main looks for an input file whose name is specified on the argument line: e.g. program input_file*/void main(int argc, char *argv[]){ if (argc != 2) { fprintf(stderr,"Usage: program <input_file>\n"); exit(1); } if ((fp = fopen(argv[1],"r")) == NULL) { fprintf(stderr,"File %s cannot be read from\n",argv[1]); exit(1); } getsetup(); outputcipher(); } When I build and run this prog. i get the message"Failed to launch there are no binaries" Please help. Freddy. seems ok. Can you help with this please? ========================================================================> Date: Mon, 26 May 2008 10:14:08 -0400> From: ea...@us...> To: min...@li...> Subject: Re: [Mingw-users] Where to install a DLL> > > Quoting Erik de Castro Lopo <ml...@me...>:> > > Hi all,> >> > Ok, I have some code that I've successfully compiled into a DLL> > and I'm about to wrap an automated installer around it. The installer> > will install the following:> >> > - The DLL itself.> > - Developer documentation.> > - A couple of small demo programs that use the DLL.> > - Example source code.> >> > So where should the installer put the DLL? Lots of programs use> > this DLL so the obvious solution seems to be C:\System, but that> > seems to be considered bad form.> >> > Any suggestions?> > I would put the .dll files with the .exe files. The Windows OS will > find it in that directory. If this is a development library then > you'll also have header files and import libraries as well I assume. > So if I have package foo then I would install into foo/bin, foo/lib, > foo/include, foo/samples and foo/docs. No other consideration should > be made as to where to install and no other consideration for modifying > PATH should be done in the install. The developers who use your dll > will need to ship it with their executable to make the executable > functioning.> > Earnie> > -------------------------------------------------------------------------> This SF.net email is sponsored by: Microsoft> Defy all challenges. Microsoft(R) Visual Studio 2008.> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/> _______________________________________________> MinGW-users mailing list> Min...@li...> > You may change your MinGW Account Options or unsubscribe at:> https://lists.sourceforge.net/lists/listinfo/mingw-users _________________________________________________________________ Tired of having no room left in your inbox? Windows Live Hotmail now gives you 5GB of FREE storage! Get your free Windows Live Hotmail account here! http://get.live.com/mail/overview |
From: Erik de C. L. <ml...@me...> - 2008-05-26 21:00:47
|
Earnie Boyd wrote: > I would put the .dll files with the .exe files. The Windows OS will > find it in that directory. Yes, but only for those .exe files in the same directory. > If this is a development library then > you'll also have header files and import libraries as well I assume. This library is already used by hundreds if not thousands of existing windows programs. > So if I have package foo then I would install into foo/bin, foo/lib, > foo/include, foo/samples and foo/docs. That was my intention. > No other consideration should > be made as to where to install and no other consideration for modifying > PATH should be done in the install. The developers who use your dll > will need to ship it with their executable to make the executable > functioning. The thing is, I expect the majority of people who install my DLL to be users, not developers. To expect these users to run my installer and then find all the old versions of the library and copy the new version over the top of the old is simply too much for most dumb users. I expect developers who use my library to use my installer for my library. My installer would find the existing version of the library in the windows system directory, check its version and only replace it if the new version is older than the new version. Personally I think this is far more sane than the way things are normally done on the windows platform. Erik -- ----------------------------------------------------------------- Erik de Castro Lopo ----------------------------------------------------------------- "C++ is the only current language making COBOL look good." -- Bertrand Meyer |
From: Greg C. <gch...@sb...> - 2008-05-26 22:16:55
|
On 2008-05-26 21:00Z, Erik de Castro Lopo wrote: > > This library is already used by hundreds if not thousands of > existing windows programs. [...] > I expect developers who use my library to use my installer for my > library. What's the probability, though, that all the developers of all those programs will heed your recommendation? > My installer would find the existing version of the > library in the windows system directory, check its version and > only replace it if the new version is older than the new version. If you ever need to change the ABI of your dll, then doesn't that break any application that used an older version? > Personally I think this is far more sane than the way things are > normally done on the windows platform. One copy in the windows system directory, upgraded to any newer version as it becomes available--isn't that the way things were classically done on msw? See, e.g.: http://en.wikipedia.org/wiki/DLL_hell |
From: Erik de C. L. <ml...@me...> - 2008-05-26 22:28:58
|
Greg Chicares wrote: > If you ever need to change the ABI of your dll, then doesn't > that break any application that used an older version? This is a library that was born on Unix and stick rock solid to the Unix libname.so.X.Y.Z conventions. On windows, this becomes libname-X.dll. Breaking the API means that X changes. > One copy in the windows system directory, upgraded to any > newer version as it becomes available--isn't that the way > things were classically done on msw? See, e.g.: > > http://en.wikipedia.org/wiki/DLL_hell But using the above libname-X.DLL scheme (and sticking by the rule of incrementing X when the ABI changes) should prevent that shouldn't it? Erik -- ----------------------------------------------------------------- Erik de Castro Lopo ----------------------------------------------------------------- Only people who suck have a problem with elitism. |
From: Roumen P. <bug...@ro...> - 2008-05-27 19:05:28
|
Erik de Castro Lopo wrote: > [SNIP] > But using the above libname-X.DLL scheme (and sticking by the > rule of incrementing X when the ABI changes) should prevent that > shouldn't it? No. It look like name generated from libtool and algorithm to compute X in win32 case is no so usefull. Roumen |
From: Ralf W. <Ral...@gm...> - 2008-05-27 20:50:12
|
Hello Roumen, * Roumen Petrov wrote on Tue, May 27, 2008 at 09:05:18PM CEST: > Erik de Castro Lopo wrote: > > [SNIP] > > But using the above libname-X.DLL scheme (and sticking by the > > rule of incrementing X when the ABI changes) should prevent that > > shouldn't it? > No. It look like name generated from libtool and algorithm to compute X > in win32 case is no so usefull. Can you please substantiate that claim? Thanks, Ralf |
From: Roumen P. <bug...@ro...> - 2008-05-27 21:36:05
|
Ralf Wildenhues wrote: > Hello Roumen, > > * Roumen Petrov wrote on Tue, May 27, 2008 at 09:05:18PM CEST: >> Erik de Castro Lopo wrote: >>> [SNIP] >>> But using the above libname-X.DLL scheme (and sticking by the >>> rule of incrementing X when the ABI changes) should prevent that >>> shouldn't it? >> No. It look like name generated from libtool and algorithm to compute X >> in win32 case is no so usefull. > > Can you please substantiate that claim? > > Thanks, > Ralf cygwin/mingw case: 1) X=version=current-age, i.e libfoo-X.dll; 2) if interface is added=> ++current, ++age => version is same X, i.e. libfoo-X.dll; If program is linked with library from 2) and use new interface it will fail on system where exist 1) . May be I don't understand libtool versioning system properly. Roumen |
From: John B. <joh...@ho...> - 2008-05-27 23:00:10
|
Roumen Petrov wrote: ---------------------------------------- > > Ralf Wildenhues wrote: >> Hello Roumen, >> >> * Roumen Petrov wrote on Tue, May 27, 2008 at 09:05:18PM CEST: >>> Erik de Castro Lopo wrote: >>>> [SNIP] >>>> But using the above libname-X.DLL scheme (and sticking by the >>>> rule of incrementing X when the ABI changes) should prevent that >>>> shouldn't it? >>> No. It look like name generated from libtool and algorithm to compute X >>> in win32 case is no so usefull. >> >> Can you please substantiate that claim? >> >> Thanks, >> Ralf > cygwin/mingw case: > 1) X=version=current-age, i.e libfoo-X.dll; > 2) if interface is added=> ++current, ++age => version is same X, i.e. > libfoo-X.dll; > If program is linked with library from 2) and use new interface it will > fail on system where exist 1) . > > May be I don't understand libtool versioning system properly. > > Roumen When you run your program, you will get a message: 'libname-X+1 not found' or something similar. Now you know whet the problem is. All you have to do is get a copy of libname-X+1.dll from the developer. So now you have libname-X.dll *and* libname-X+1.dll on your system. The other programs that use libname-X.dll will work, and your program that needs libname-X+1.dll will also work, and they will not interfere with each other. _________________________________________________________________ Keep your kids safer online with Windows Live Family Safety. http://www.windowslive.com/family_safety/overview.html?ocid=TXT_TAGLM_WL_Refresh_family_safety_052008 |
From: Ralf W. <Ral...@gm...> - 2008-05-28 04:10:00
|
* Roumen Petrov wrote on Tue, May 27, 2008 at 11:35:56PM CEST: > Ralf Wildenhues wrote: >> * Roumen Petrov wrote on Tue, May 27, 2008 at 09:05:18PM CEST: >>> No. It look like name generated from libtool and algorithm to compute >>> X in win32 case is no so usefull. >> >> Can you please substantiate that claim? > cygwin/mingw case: > 1) X=version=current-age, i.e libfoo-X.dll; > 2) if interface is added=> ++current, ++age => version is same X, i.e. > libfoo-X.dll; > If program is linked with library from 2) and use new interface it will > fail on system where exist 1) . Sure. But that's no different from how major versions work on, say, Linux. If you use the library from (2), it will work with both old and new ones. It is a backward compatible interface change. If Libtool had chosen instead to rename a library upon each compatible (and not just each incompatible) interface change, then there would be literally no chance to share libraries at all, for such compatible changes are very common. This is all no different on most other systems, you cannot expect to install an older version over a newer one and expect things to work. Cheers, Ralf |
From: Roumen P. <bug...@ro...> - 2008-05-29 21:23:27
|
Ralf Wildenhues wrote: > * Roumen Petrov wrote on Tue, May 27, 2008 at 11:35:56PM CEST: >> Ralf Wildenhues wrote: >>> * Roumen Petrov wrote on Tue, May 27, 2008 at 09:05:18PM CEST: >>>> No. It look like name generated from libtool and algorithm to compute >>>> X in win32 case is no so usefull. >>> Can you please substantiate that claim? > >> cygwin/mingw case: >> 1) X=version=current-age, i.e libfoo-X.dll; >> 2) if interface is added=> ++current, ++age => version is same X, i.e. >> libfoo-X.dll; >> If program is linked with library from 2) and use new interface it will >> fail on system where exist 1) . > > Sure. But that's no different from how major versions work on, say, > Linux. If you use the library from (2), it will work with both old > and new ones. It is a backward compatible interface change. I'm not sure. Let application A and B use libfoo-N.dll, A is build against library form 1) and B - from 2) and use new interface. Install scenarios: - without to replace library if version is same: Let application A is installed first and B second then B will fail to run since new interface is missing in library. - with replacement of library: Let application B is installed first and A second. Since installation of A replace library existing application B will fail to run. > If Libtool had chosen instead to rename a library upon each compatible > (and not just each incompatible) interface change, then there would be > literally no chance to share libraries at all, for such compatible > changes are very common. This is all no different on most other > systems, you cannot expect to install an older version over a newer one > and expect things to work. In the current libtool versioning mingw scheme I don't know how to distinguish cleanly cases 1) and 2). One solution is libtool link flag -release. Other is with resource file where to put release info. > Cheers, > Ralf Roumen |
From: Charles W. <cwi...@us...> - 2008-05-30 01:33:31
|
Roumen Petrov wrote: > I'm not sure. Let application A and B use libfoo-N.dll, A is build > against library form 1) and B - from 2) and use new interface. > Install scenarios: > - without to replace library if version is same: > Let application A is installed first and B second then B will fail to > run since new interface is missing in library. > > - with replacement of library: > Let application B is installed first and A second. Since installation of > A replace library existing application B will fail to run. You're confusing backwards-compatibility with forward-compatibility (aka: total interface deep-freeze). B requires the latest version of libfoo-N.dll A requires any version of libfoo-N.dll The most recent version of libfoo-N.dll satisfies both requirements. It is *backwards* compatible with any application that uses it, or any older version, of libfoo-N.dll. However, libfoo-N is not guaranteed to be forward compatible with any newer version that library (even if the dll number, c-a, doesn't change). That is, future versions of libfoo-N that do *not* change or remove existing entry points are expressly allowed to add *new* entry points. And future apps are expressly allowed to use those entry points. This means these future apps won't work with current or old libfoo-N -- but that is easily fixed: just install the most recent version of libfoo-N at any given time, and /all/ existing apps will be happy. Requiring to change "N" every time a new entry point is added, even when nothing else changes, leads to a gigantic proliferation of DLLs -- in the extreme case, every app needs its own version of the library, and you might as well just link statically. And nobody would bother fixing bugs in libfoo-1322.dll, because they'd just wait and recompile against libfoo-1452.dll (which in actual practice means that end-users keep using #1322 with the bug). The libtool system isn't perfect, but it has been well-tested and has served the cygwin distribution very well for eight years or so, with very few issues. -- Chuck |
From: Roumen P. <bug...@ro...> - 2008-05-31 13:08:10
|
Charles Wilson wrote: > Roumen Petrov wrote: >> I'm not sure. Let application A and B use libfoo-N.dll, A is build >> against library form 1) and B - from 2) and use new interface. >> Install scenarios: >> - without to replace library if version is same: >> Let application A is installed first and B second then B will fail to >> run since new interface is missing in library. >> >> - with replacement of library: >> Let application B is installed first and A second. Since installation of >> A replace library existing application B will fail to run. > > You're confusing backwards-compatibility with forward-compatibility > (aka: total interface deep-freeze). No > B requires the latest version of libfoo-N.dll > A requires any version of libfoo-N.dll And the application that require "latest" version of "libfoo-N.dll" cannot determine this from library name. So the installation of an application require additional info to find out which version is installed before to replace library. > The most recent version of libfoo-N.dll satisfies both requirements. It > is *backwards* compatible with any application that uses it, or any > older version, of libfoo-N.dll. > > However, libfoo-N is not guaranteed to be forward compatible with any > newer version that library (even if the dll number, c-a, doesn't > change). That is, future versions of libfoo-N that do *not* change or > remove existing entry points are expressly allowed to add *new* entry > points. And future apps are expressly allowed to use those entry points. > This means these future apps won't work with current or old libfoo-N -- > but that is easily fixed: just install the most recent version of > libfoo-N at any given time, and /all/ existing apps will be happy. > > Requiring to change "N" every time a new entry point is added, even when > nothing else changes, leads to a gigantic proliferation of DLLs -- in > the extreme case, every app needs its own version of the library, and > you might as well just link statically. And nobody would bother fixing > bugs in libfoo-1322.dll, because they'd just wait and recompile against > libfoo-1452.dll (which in actual practice means that end-users keep > using #1322 with the bug). > > The libtool system isn't perfect, but it has been well-tested and has > served the cygwin distribution very well for eight years or so, with > very few issues. As far as know cygwin setup use "package release version" to chose to upgrade or not existing library. This is additional info that avoid problem. > -- > Chuck Roumen |
From: Earnie B. <ea...@us...> - 2008-05-31 15:40:21
|
Quoting Roumen Petrov <bug...@ro...>: > Charles Wilson wrote: >> Roumen Petrov wrote: >>> I'm not sure. Let application A and B use libfoo-N.dll, A is build >>> against library form 1) and B - from 2) and use new interface. >>> Install scenarios: >>> - without to replace library if version is same: >>> Let application A is installed first and B second then B will fail to >>> run since new interface is missing in library. >>> >>> - with replacement of library: >>> Let application B is installed first and A second. Since installation of >>> A replace library existing application B will fail to run. >> >> You're confusing backwards-compatibility with forward-compatibility >> (aka: total interface deep-freeze). > > No > > >> B requires the latest version of libfoo-N.dll >> A requires any version of libfoo-N.dll > > And the application that require "latest" version of "libfoo-N.dll" > cannot determine this from library name. > So the installation of an application require additional info to find > out which version is installed before to replace library. > Can't you LoadLibrary and GetProcAddr for a function that returns the version? You make this harder than it needs to be. In reference to Cygwin and backward compatibility: Care has been taken to avoid needing to upgrade everything every time a new release of the runtime has happened since the year of 1996. You replace the DLL and move on with life as needed. Earnie |
From: Charles W. <cwi...@us...> - 2008-05-31 17:30:05
|
Earnie Boyd wrote: > Can't you LoadLibrary and GetProcAddr for a function that > returns the version? You make this harder than it needs to be. Rouman is arguing that the libtool naming scheme for DLLs on win32 is not sufficient for his needs, and wants to change libtool. Or at least, that's how this thread reads to me. I'm arguing that we shouldn't break a working model to accommodate a few corner cases that can use alternate mechanisms (such as --release, etc -- if they really ARE corner cases not well served by the libtool model. I'm additionally arguing that the DLL-naming aspect of libtool does not need to be, and should not be, changed. > In reference to Cygwin and backward compatibility: Care has > been taken to avoid needing to upgrade everything every time > a new release of the runtime has happened since the year of > 1996. You replace the DLL and move on with life as needed. Off point. I'm talking about DLLs from other libraries within the cygwin milieu, such as cygncurses-8.dll or cygintl-3.dll. Not cygwin1.dll -- which is not built using libtool anyway. -- Chuck |
From: Roumen P. <bug...@ro...> - 2008-05-31 23:45:12
|
Charles Wilson wrote: > Earnie Boyd wrote: > > > Can't you LoadLibrary and GetProcAddr for a function that > > returns the version? You make this harder than it needs to be. > > Rouman is arguing that the libtool naming scheme for DLLs on win32 is > not sufficient for his needs, and wants to change libtool. My first reply was on following sentence from Erik de Castro Lopo: =============== This is a library that was born on Unix and stick rock solid to the Unix libname.so.X.Y.Z conventions. On windows, this becomes libname-X.dll. =============== I would like just to point that mingw underling operating system don't support "rock solid" library versioning system itself and do not expect that libtool will resolve this issue. From the quoted text above I assume that library is build with -version-info option(argument) passed to libtool. > Or at least, > that's how this thread reads to me. I'm arguing that we shouldn't break > a working model to accommodate a few corner cases that can use alternate > mechanisms (such as --release, etc -- if they really ARE corner cases > not well served by the libtool model. I'm additionally arguing that the > DLL-naming aspect of libtool does not need to be, and should not be, > changed. I'm not sure that I would like libtool project to change how libtool versioning system is implemented for host systems like mingw/cygwin. I think that library authors has to care more if a shared library , produced by libtool for mingw host, is installed in a common to "operating system dynamic library search" path (it is not like unix ;) ). The advanced dynamic library loader (that is missing on underling operating system) is may be the best solution but this is not is scope neither of libtool nor mingw. So "where to install a dll" is very good question and we may continue mail thread in direction "mingw package system". > > In reference to Cygwin and backward compatibility: Care has > > been taken to avoid needing to upgrade everything every time > > a new release of the runtime has happened since the year of > > 1996. You replace the DLL and move on with life as needed. > > Off point. I'm talking about DLLs from other libraries within the cygwin > milieu, such as cygncurses-8.dll or cygintl-3.dll. Not cygwin1.dll -- > which is not built using libtool anyway. Ok. Roumen |
From: Earnie B. <ea...@us...> - 2008-06-01 01:46:23
|
Quoting Roumen Petrov <bug...@ro...>: > > So "where to install a dll" is very good question and we may continue > mail thread in direction "mingw package system". > Where it matters, with the executable it goes in <install prefix>/bin. If developers are using MinGW they would most likely install to their MinGW prefix; commonly c:/mingw/bin. Earnie |
From: Ralf W. <Ral...@gm...> - 2008-06-01 07:30:17
|
* Roumen Petrov wrote on Sun, Jun 01, 2008 at 01:45:04AM CEST: > My first reply was on following sentence from Erik de Castro Lopo: > =============== > This is a library that was born on Unix and stick rock solid > to the Unix libname.so.X.Y.Z conventions. On windows, this > becomes libname-X.dll. > =============== Yes. But I think you are still misunderstanding how things work on Unices. On Linux, as an example, there are typically symlinks libname.so and libname.so.X to libname.so.X.Y.Z, too. The former is so that newly linked programs pick up the newest library with the soname of libname.so.X, the second is that the runtime linker finds dependent libraries by their soname. The soname is the important thing, and that is libname.so.X under Linux, not libname.s.X.Y.Z. So it helps you nothing that you can have several libraries installed with different Y and Z, you *still* have to take care that the newest one is the one pointed to by libname.so.X. FWIW, I'm specifically saying Linux here, because the details do differ on many other unices; FWIW2, I apologize for having to bring up this slightly off-topic discourse here. > I would like just to point that mingw underling operating system don't > support "rock solid" library versioning system itself and do not expect > that libtool will resolve this issue. > From the quoted text above I assume that library is build with > -version-info option(argument) passed to libtool. There is absolutely no issue with the library naming scheme on w32 *if* you stick to the policy of always installing the *newest* such lib under the name libname-X.dll. That's really no bit different under Unix, either. > So "where to install a dll" is very good question and we may continue > mail thread in direction "mingw package system". Good idea. Please keep in mind that a packaging system is exactly the right place to execute the policy of always having the newest of a compatible library installed. Cheers, Ralf |
From: Earnie B. <ea...@us...> - 2008-05-27 15:44:35
|
Quoting Erik de Castro Lopo <ml...@me...>: > > The thing is, I expect the majority of people who install my DLL to > be users, not developers. To expect these users to run my installer > and then find all the old versions of the library and copy the new > version over the top of the old is simply too much for most dumb > users. > > I expect developers who use my library to use my installer for my > library. My installer would find the existing version of the > library in the windows system directory, check its version and > only replace it if the new version is older than the new version. > > Personally I think this is far more sane than the way things are > normally done on the windows platform. > You expect too much; I am speaking from experience. Store the data in the registry; then you can control the upgrades for your users. However, if your library is truly open source then I am free to do what ever with it and there is no guarantee that a user is sane in her installation processes nor is there a guarantee that a developer will be sane with his distribution of your library. By "sane" I mean your expected use or expected idea of how the install should be done. Earnie |