[now vw7.9] msvcr100.dll Re: vw7.8 64-bit on windows error
Locked
12
12
[now vw7.9] msvcr100.dll Re: vw7.8 64-bit on windows error
 
|
>From the 7.9 release notes:
"Windows OE DLL Requirement Due to a compiler upgrade, the Windows VMs require that msvcr100.dll be installed in its proper location (System32 or SysWOW64).If this DLL is not already installed, the installer installs and runs a program (VisualWorks32bitDLLPrereqs, and VisualWorks64bitDLLPrereqs on 64-bit systems) that installs the DLL(s) and registers VisualWorks’ interest in them. After installation, an information screen tells you this has been done. If you uninstall this program, VisualWorks is deregistered for it, and the DLL is removed if no other program has an interest. When deploying an application with the VM, you are responsible for ensuring that this file is present on the target system." So, this is now required for 32-bit VisualWorks on Windows also? This is going to be very, very inconvenient for me. The single file VM and the ability to embed the image in the VM are one of the reasons I chose VisualWorks. Up to this point I have not needed any extra libraries and this is very important to me and to my customers. The msvcr100.dll throws a real monkey wrench into things for me. I hope that Cincom will decide to statically link whatever functions it needs from this DLL going forward. I may be forced to stick with 7.8 otherwise. -Carl Gundel http://www.libertybasic.com http://www.runbasic.com On Sun, Feb 20, 2011 at 10:29 AM, Alan Knight <[hidden email]> wrote: > > Yes, this is expected. We'll need to do something about that, but for 7.8, > where win64 is in preview, I think it's likely to remain and we'll sort out > the various possibilities with a bit more time to consider. > > > On 11-02-20 6:36 AM, Steffen Märcker wrote: >> >> >> I've just attempted to start the win64 vm on Windows 7 Prof. 64 Bit and >> got the message to install msvcr100.dll too. Do I understand this thread >> right that this is actually expected? >> >> Regards, Steffen >> >> >> Am 11.02.2011, 11:17 Uhr, schrieb Steven Kelly <[hidden email]>: >> >>> I just went through all VW monolithic VMs from 2.0 to 7.7.1 with >>> Dependency Walker: >>> >>> 2.0 and 2.5 statically linked any functions they called from msvcrt.dll >>> >>> 3.0 dynamically linked msvcrt40.dll, but 3.0b already changed that to >>> just msvcrt.dll. >>> >>> 5i.3 - 7.7.1 have all dynamically linked msvcrt.dll, which has been an >>> obligatory part of standard Windows installs for over a decade >>> <http://en.wikipedia.org/wiki/Microsoft_Windows_library_files#Msvcrt.dll >>>> >>>> (Windows 2000 on), in Windows\system32 (and before that part of a >>> >>> normal Windows install since at least Windows 95 >>> <http://support.microsoft.com/kb/895959> ). >>> >>> >>> There's a big difference >>> <http://msdn.microsoft.com/en-us/library/abx4dbyh(VS.71).aspx#CodeSpippe >>> t0> between msvcrt.dll (a system file) and msvcr[71-100].dll. The >>> former is guaranteed to be found (although you have no control over the >>> exact version), the latter must be installed with your application. >>> >>> >>> In theory you shouldn't rely on the system msvcrt.dll, since it will be >>> a different version from what you used in your own testing, but in >>> practice for VW this seems to have worked well. I imagine VW's reliance >>> is pretty generic and stable, so it's been more likely that things >>> improved when MS shipped an update to msvcrt.dll, than that things would >>> break. XP SP2 was the exception, as the significant changes it >>> introduced caused problems in many applications. It looks like Microsoft >>> are moving away from allowing 3rd party apps to dynamically link to the >>> system msvcrt.dll, so Cincom should stop too. There's a good discussion >>> <http://stackoverflow.com/questions/1073509/should-i-redistribute-msvcrt >>> -dll-with-my-application> on the pros and cons on StackOverflow. >>> >>> >>> So, with the exception of 3.0 (which was corrected in 3.0b), no previous >>> VM has dynamically depended on a particular msvcr[40-100].dll. Those >>> particular DLLs aren't shipped with Windows, and if you depend on them >>> you MUST ship them. >>> >>> >>> Better though would be to statically link the CRT for the 64-bit VM, >>> using /MT. That would also seem to be good advice for the 32-bit VM, to >>> remove the dependency on the system msvcrt.dll. Statically linking the >>> 64-bit VM will also significantly reduce the total size of the >>> application, since I imagine VW only uses a tiny fraction of the whole >>> msvcrt100.dll. >>> >>> >>> Cheers, >>> >>> Steve >>> >>> >>> >>> From: [hidden email] [mailto:[hidden email]] On >>> Behalf Of Alan Knight >>> Sent: 11. helmikuuta 2011 1:34 >>> To: [hidden email] >>> Subject: Re: vw7.8 64-bit on windows error >>> >>> >>> I don't think we have statically linked the MSVCR libraries in previous >>> versions, at least not for a very long time. I also don't think that >>> those libraries are part of the Windows installs, but they tended to be >>> there if you'd installed anything at all. And possibly if the operating >>> system included programs that were built with those compilers they would >>> be for practical purposes included. The difference in this case is, I >>> suspect, that people have fewer things installed that are 64-bit >>> applications, and the compiler is newer. >>> >>> It is not needed on 32-bit installations, because we are for the moment >>> still using an older compiler version for the 32-bit versions, partly >>> because of that dependency. Building the 64-bit versions required the >>> use of the more recent compiler. 32-bit versions appear to my untrained >>> eye to require MSVCRT.DLL with no version number embedded in the name. I >>> don't believe it makes any difference between visual.exe and vwnt.exe. >>> >>> It's possible that we really ought to be installing it, but it is not >>> something we've ever done in the past and it does not seem to have >>> previously been an issue. >>> >>> >>> >>> In earlier versions, the necessary parts of the MSVCR library have been >>> statically linked (IIRC), or then the relevant library has been part of >>> a normal Windows installation anyway (maybe in IE?). Even the Cairo DLL >>> was kindly made by Travis to be statically linked rather than require >>> MSCVR90.dll: >>> >>> http://www.parcplace.net/list/vwnc-archive/0910/msg00085.html >>> >>> Information on static linking and msvcr100.dll is in the last message >>> here: >>> >>> http://social.msdn.microsoft.com/Forums/en/vssetup/thread/6891665f-fd83- >>> 426a-9d73-69d6d7e171a3 >>> >>> >>> As Martin said, a vendor using a redistributable dynamically linked >>> library like this is expected to ship it as part of their installer - as >>> can be seen from e.g. InstallShield, which comes with a wide range of >>> redistributables that install builders can add to their install. It's >>> also what Microsoft says to do (IIUC): >>> >>> http://msdn.microsoft.com/en-us/library/ms235299.aspx >>> >>> "If you use a merge module that contains a Visual C++ DLL, you must >>> include it in the Windows Installer package (or similar installation >>> package) that you are using to deploy the application" >>> >>> >>> Of course, all this is just for what Cincom should do when providing >>> their product, if that product were just an application. Given the >>> product in this case is a development environment, Cincom should also >>> provide automation and/or instructions for developers to create and >>> deploy their own products - including any necessary redistributables. >>> Otherwise end users are going to be reporting that the application >>> doesn't work, and developers aren't going to understand why (and >>> presumably Cincom isn't going to get any royalties in that case!). >>> >>> >>> Is msvcr100.dll also needed on 32-bit VW 7.8 installations on Windows? >>> Does it make a difference if we use the monolithic visual.exe VM or the >>> split .exe+.dll VM? >>> >>> >>> Cheers, >>> >>> Steve >>> >>> >>> >>> ________________________________ >>> >>> From: [hidden email] on behalf of Alan Knight >>> Sent: Thu 10/02/2011 19:55 >>> To: Martin McClure >>> Cc: [hidden email] >>> Subject: Re: vw7.8 64-bit on windows error >>> >>> >>> That isn't something we've done in the past. I think that typically >>> those libraries end up installed quite widely as soon as you've >>> installed anything. And it would be a bit tricky, in that it wouldn't be >>> integrated with our installation mechanisms. I think about the best we >>> could do at this point would be to include a copy on the CD or download >>> and people would have to install it themselves. We can also look into >>> trying to do something in the next release when we expect to have Win64 >>> as fully supported, but it's quite late to try much for this one. >>> >>> On 2011-02-10 12:09 AM, Martin McClure wrote: >>>> >>>> On 02/09/11 11:11, Alan Knight wrote: >>>>> >>>>> you need to install the appropriate MS >>>>> runtime for the most recent compiler. >>>> >>>> I'd gotten the impression that Microsoft's intent is that when an >>>> application requires a particular version of the MSVCR library, the >>>> application vendor should ship that MSVCR library along with the >>>> application. >>>> >>>> Would it be possible to include that with the Windows install? >>>> >>>> Regards, >>>> >>>> -Martin >>> >>> >>> -- >>> Alan Knight [|], Engineering Manager, Cincom Smalltalk >>> [hidden email] >>> [hidden email] >>> http://www.cincomsmalltalk.com <http://www.cincomsmalltalk.com/> >>> >>> >>> >>> > _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: [now vw7.9] msvcr100.dll Re: vw7.8 64-bit on windows error
|
|
Yes, this is going to be a show-stopper for using VW 7.9 for me as well :-(
But since linking the DLLs statically to the VMs for Windows needs to be done only once, maybe somebody did this and could share the VM with the community? I wonder why Cincom is not able to provide such a VM... Is it so hard to do or are there legal issues involved? I really hope that there will be a practical solution to this problem without having to dive into C land to figure out how to do that myself... Christian > -----Ursprüngliche Nachricht----- > Von: [hidden email] [mailto:[hidden email]] Im > Auftrag von Carl Gundel > Gesendet: Sonntag, 15. Juli 2012 06:31 > An: VWNC List > Betreff: [vwnc] [now vw7.9] msvcr100.dll Re: vw7.8 64-bit on windows error > > >From the 7.9 release notes: > > "Windows OE DLL Requirement > Due to a compiler upgrade, the Windows VMs require that msvcr100.dll be > installed in its proper location (System32 or SysWOW64).If this DLL is not > already installed, the installer installs and runs a program > (VisualWorks32bitDLLPrereqs, and VisualWorks64bitDLLPrereqs on 64-bit > systems) that installs the DLL(s) and registers VisualWorks' interest in them. > After installation, an information screen tells you this has been done. If you > uninstall this program, VisualWorks is deregistered for it, and the DLL is > removed if no other program has an interest. > When deploying an application with the VM, you are responsible for ensuring > that this file is present on the target system." > > So, this is now required for 32-bit VisualWorks on Windows also? > > This is going to be very, very inconvenient for me. The single file VM and the > ability to embed the image in the VM are one of the reasons I chose > VisualWorks. Up to this point I have not needed any extra libraries and this is > very important to me and to my customers. The msvcr100.dll throws a real > monkey wrench into things for me. I hope that Cincom will decide to > statically link whatever functions it needs from this DLL going forward. I may > be forced to stick with 7.8 otherwise. > > -Carl Gundel > http://www.libertybasic.com > http://www.runbasic.com > > On Sun, Feb 20, 2011 at 10:29 AM, Alan Knight <[hidden email]> wrote: > > > > Yes, this is expected. We'll need to do something about that, but for > > 7.8, where win64 is in preview, I think it's likely to remain and > > we'll sort out the various possibilities with a bit more time to consider. > > > > > > On 11-02-20 6:36 AM, Steffen Märcker wrote: > >> > >> > >> I've just attempted to start the win64 vm on Windows 7 Prof. 64 Bit > >> and got the message to install msvcr100.dll too. Do I understand this > >> thread right that this is actually expected? > >> > >> Regards, Steffen > >> > >> > >> Am 11.02.2011, 11:17 Uhr, schrieb Steven Kelly <[hidden email]>: > >> > >>> I just went through all VW monolithic VMs from 2.0 to 7.7.1 with > >>> Dependency Walker: > >>> > >>> 2.0 and 2.5 statically linked any functions they called from > >>> msvcrt.dll > >>> > >>> 3.0 dynamically linked msvcrt40.dll, but 3.0b already changed that > >>> to just msvcrt.dll. > >>> > >>> 5i.3 - 7.7.1 have all dynamically linked msvcrt.dll, which has been > >>> an obligatory part of standard Windows installs for over a decade > >>> <http://en.wikipedia.org/wiki/Microsoft_Windows_library_files#Msvcrt > >>> .dll > >>>> > >>>> (Windows 2000 on), in Windows\system32 (and before that part of a > >>> > >>> normal Windows install since at least Windows 95 > >>> <http://support.microsoft.com/kb/895959> ). > >>> > >>> > >>> There's a big difference > >>> <http://msdn.microsoft.com/en- > us/library/abx4dbyh(VS.71).aspx#CodeSp > >>> ippe > >>> t0> between msvcrt.dll (a system file) and msvcr[71-100].dll. The > >>> former is guaranteed to be found (although you have no control over > >>> the exact version), the latter must be installed with your application. > >>> > >>> > >>> In theory you shouldn't rely on the system msvcrt.dll, since it will > >>> be a different version from what you used in your own testing, but > >>> in practice for VW this seems to have worked well. I imagine VW's > >>> reliance is pretty generic and stable, so it's been more likely that > >>> things improved when MS shipped an update to msvcrt.dll, than that > >>> things would break. XP SP2 was the exception, as the significant > >>> changes it introduced caused problems in many applications. It looks > >>> like Microsoft are moving away from allowing 3rd party apps to > >>> dynamically link to the system msvcrt.dll, so Cincom should stop > >>> too. There's a good discussion > >>> <http://stackoverflow.com/questions/1073509/should-i-redistribute-ms > >>> vcrt > >>> -dll-with-my-application> on the pros and cons on StackOverflow. > >>> > >>> > >>> So, with the exception of 3.0 (which was corrected in 3.0b), no > >>> previous VM has dynamically depended on a particular > >>> msvcr[40-100].dll. Those particular DLLs aren't shipped with > >>> Windows, and if you depend on them you MUST ship them. > >>> > >>> > >>> Better though would be to statically link the CRT for the 64-bit VM, > >>> using /MT. That would also seem to be good advice for the 32-bit VM, > >>> to remove the dependency on the system msvcrt.dll. Statically > >>> linking the 64-bit VM will also significantly reduce the total size > >>> of the application, since I imagine VW only uses a tiny fraction of > >>> the whole msvcrt100.dll. > >>> > >>> > >>> Cheers, > >>> > >>> Steve > >>> > >>> > >>> > >>> From: [hidden email] [mailto:vw-dev- > [hidden email]] > >>> On Behalf Of Alan Knight > >>> Sent: 11. helmikuuta 2011 1:34 > >>> To: [hidden email] > >>> Subject: Re: vw7.8 64-bit on windows error > >>> > >>> > >>> I don't think we have statically linked the MSVCR libraries in > >>> previous versions, at least not for a very long time. I also don't > >>> think that those libraries are part of the Windows installs, but > >>> they tended to be there if you'd installed anything at all. And > >>> possibly if the operating system included programs that were built > >>> with those compilers they would be for practical purposes included. > >>> The difference in this case is, I suspect, that people have fewer > >>> things installed that are 64-bit applications, and the compiler is newer. > >>> > >>> It is not needed on 32-bit installations, because we are for the > >>> moment still using an older compiler version for the 32-bit > >>> versions, partly because of that dependency. Building the 64-bit > >>> versions required the use of the more recent compiler. 32-bit > >>> versions appear to my untrained eye to require MSVCRT.DLL with no > >>> version number embedded in the name. I don't believe it makes any > difference between visual.exe and vwnt.exe. > >>> > >>> It's possible that we really ought to be installing it, but it is > >>> not something we've ever done in the past and it does not seem to > >>> have previously been an issue. > >>> > >>> > >>> > >>> In earlier versions, the necessary parts of the MSVCR library have > >>> been statically linked (IIRC), or then the relevant library has been > >>> part of a normal Windows installation anyway (maybe in IE?). Even > >>> the Cairo DLL was kindly made by Travis to be statically linked > >>> rather than require > >>> MSCVR90.dll: > >>> > >>> http://www.parcplace.net/list/vwnc-archive/0910/msg00085.html > >>> > >>> Information on static linking and msvcr100.dll is in the last > >>> message > >>> here: > >>> > >>> > http://social.msdn.microsoft.com/Forums/en/vssetup/thread/6891665f-f > >>> d83- > >>> 426a-9d73-69d6d7e171a3 > >>> > >>> > >>> As Martin said, a vendor using a redistributable dynamically linked > >>> library like this is expected to ship it as part of their installer > >>> - as can be seen from e.g. InstallShield, which comes with a wide > >>> range of redistributables that install builders can add to their > >>> install. It's also what Microsoft says to do (IIUC): > >>> > >>> http://msdn.microsoft.com/en-us/library/ms235299.aspx > >>> > >>> "If you use a merge module that contains a Visual C++ DLL, you must > >>> include it in the Windows Installer package (or similar installation > >>> package) that you are using to deploy the application" > >>> > >>> > >>> Of course, all this is just for what Cincom should do when providing > >>> their product, if that product were just an application. Given the > >>> product in this case is a development environment, Cincom should > >>> also provide automation and/or instructions for developers to create > >>> and deploy their own products - including any necessary > redistributables. > >>> Otherwise end users are going to be reporting that the application > >>> doesn't work, and developers aren't going to understand why (and > >>> presumably Cincom isn't going to get any royalties in that case!). > >>> > >>> > >>> Is msvcr100.dll also needed on 32-bit VW 7.8 installations on Windows? > >>> Does it make a difference if we use the monolithic visual.exe VM or > >>> the split .exe+.dll VM? > >>> > >>> > >>> Cheers, > >>> > >>> Steve > >>> > >>> > >>> > >>> ________________________________ > >>> > >>> From: [hidden email] on behalf of Alan Knight > >>> Sent: Thu 10/02/2011 19:55 > >>> To: Martin McClure > >>> Cc: [hidden email] > >>> Subject: Re: vw7.8 64-bit on windows error > >>> > >>> > >>> That isn't something we've done in the past. I think that typically > >>> those libraries end up installed quite widely as soon as you've > >>> installed anything. And it would be a bit tricky, in that it > >>> wouldn't be integrated with our installation mechanisms. I think > >>> about the best we could do at this point would be to include a copy > >>> on the CD or download and people would have to install it > >>> themselves. We can also look into trying to do something in the next > >>> release when we expect to have Win64 as fully supported, but it's quite > late to try much for this one. > >>> > >>> On 2011-02-10 12:09 AM, Martin McClure wrote: > >>>> > >>>> On 02/09/11 11:11, Alan Knight wrote: > >>>>> > >>>>> you need to install the appropriate MS runtime for the most recent > >>>>> compiler. > >>>> > >>>> I'd gotten the impression that Microsoft's intent is that when an > >>>> application requires a particular version of the MSVCR library, the > >>>> application vendor should ship that MSVCR library along with the > >>>> application. > >>>> > >>>> Would it be possible to include that with the Windows install? > >>>> > >>>> Regards, > >>>> > >>>> -Martin > >>> > >>> > >>> -- > >>> Alan Knight [|], Engineering Manager, Cincom Smalltalk > >>> [hidden email] [hidden email] http://www.cincomsmalltalk.com > >>> <http://www.cincomsmalltalk.com/> > >>> > >>> > >>> > >>> > > > > _______________________________________________ > vwnc mailing list > [hidden email] > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
|
|
While I enjoy simple deployments as much as the next guy, I'm not sure how this qualifies as a showstopper. I developed the build tool we use at my current job; when we end up in 7.9, I'll have the change a batch file to copy this file from a known location (a copy will end up being kept with a few other files we need in the image dir) to the deployment directory.
Static linking was something that used to be done with database dlls way, way back in the day, and it caused problems - people ended up being stuck on specific revs of the various databases ParcPlace supported. How does adding one file to your install procedure cause that much heartburn? On Jul 15, 2012, at 4:09 AM, Christian Haider wrote: > Yes, this is going to be a show-stopper for using VW 7.9 for me as well :-( > > But since linking the DLLs statically to the VMs for Windows needs to be done only once, maybe somebody did this and could share the VM with the community? > > I wonder why Cincom is not able to provide such a VM... Is it so hard to do or are there legal issues involved? > > I really hope that there will be a practical solution to this problem without having to dive into C land to figure out how to do that myself... > > Christian > >> -----Ursprüngliche Nachricht----- >> Von: [hidden email] [mailto:[hidden email]] Im >> Auftrag von Carl Gundel >> Gesendet: Sonntag, 15. Juli 2012 06:31 >> An: VWNC List >> Betreff: [vwnc] [now vw7.9] msvcr100.dll Re: vw7.8 64-bit on windows error >> >>> From the 7.9 release notes: >> >> "Windows OE DLL Requirement >> Due to a compiler upgrade, the Windows VMs require that msvcr100.dll be >> installed in its proper location (System32 or SysWOW64).If this DLL is not >> already installed, the installer installs and runs a program >> (VisualWorks32bitDLLPrereqs, and VisualWorks64bitDLLPrereqs on 64-bit >> systems) that installs the DLL(s) and registers VisualWorks' interest in them. >> After installation, an information screen tells you this has been done. If you >> uninstall this program, VisualWorks is deregistered for it, and the DLL is >> removed if no other program has an interest. >> When deploying an application with the VM, you are responsible for ensuring >> that this file is present on the target system." >> >> So, this is now required for 32-bit VisualWorks on Windows also? >> >> This is going to be very, very inconvenient for me. The single file VM and the >> ability to embed the image in the VM are one of the reasons I chose >> VisualWorks. Up to this point I have not needed any extra libraries and this is >> very important to me and to my customers. The msvcr100.dll throws a real >> monkey wrench into things for me. I hope that Cincom will decide to >> statically link whatever functions it needs from this DLL going forward. I may >> be forced to stick with 7.8 otherwise. >> >> -Carl Gundel >> http://www.libertybasic.com >> http://www.runbasic.com >> >> On Sun, Feb 20, 2011 at 10:29 AM, Alan Knight <[hidden email]> wrote: >>> >>> Yes, this is expected. We'll need to do something about that, but for >>> 7.8, where win64 is in preview, I think it's likely to remain and >>> we'll sort out the various possibilities with a bit more time to consider. >>> >>> >>> On 11-02-20 6:36 AM, Steffen Märcker wrote: >>>> >>>> >>>> I've just attempted to start the win64 vm on Windows 7 Prof. 64 Bit >>>> and got the message to install msvcr100.dll too. Do I understand this >>>> thread right that this is actually expected? >>>> >>>> Regards, Steffen >>>> >>>> >>>> Am 11.02.2011, 11:17 Uhr, schrieb Steven Kelly <[hidden email]>: >>>> >>>>> I just went through all VW monolithic VMs from 2.0 to 7.7.1 with >>>>> Dependency Walker: >>>>> >>>>> 2.0 and 2.5 statically linked any functions they called from >>>>> msvcrt.dll >>>>> >>>>> 3.0 dynamically linked msvcrt40.dll, but 3.0b already changed that >>>>> to just msvcrt.dll. >>>>> >>>>> 5i.3 - 7.7.1 have all dynamically linked msvcrt.dll, which has been >>>>> an obligatory part of standard Windows installs for over a decade >>>>> <http://en.wikipedia.org/wiki/Microsoft_Windows_library_files#Msvcrt >>>>> .dll >>>>>> >>>>>> (Windows 2000 on), in Windows\system32 (and before that part of a >>>>> >>>>> normal Windows install since at least Windows 95 >>>>> <http://support.microsoft.com/kb/895959> ). >>>>> >>>>> >>>>> There's a big difference >>>>> <http://msdn.microsoft.com/en- >> us/library/abx4dbyh(VS.71).aspx#CodeSp >>>>> ippe >>>>> t0> between msvcrt.dll (a system file) and msvcr[71-100].dll. The >>>>> former is guaranteed to be found (although you have no control over >>>>> the exact version), the latter must be installed with your application. >>>>> >>>>> >>>>> In theory you shouldn't rely on the system msvcrt.dll, since it will >>>>> be a different version from what you used in your own testing, but >>>>> in practice for VW this seems to have worked well. I imagine VW's >>>>> reliance is pretty generic and stable, so it's been more likely that >>>>> things improved when MS shipped an update to msvcrt.dll, than that >>>>> things would break. XP SP2 was the exception, as the significant >>>>> changes it introduced caused problems in many applications. It looks >>>>> like Microsoft are moving away from allowing 3rd party apps to >>>>> dynamically link to the system msvcrt.dll, so Cincom should stop >>>>> too. There's a good discussion >>>>> <http://stackoverflow.com/questions/1073509/should-i-redistribute-ms >>>>> vcrt >>>>> -dll-with-my-application> on the pros and cons on StackOverflow. >>>>> >>>>> >>>>> So, with the exception of 3.0 (which was corrected in 3.0b), no >>>>> previous VM has dynamically depended on a particular >>>>> msvcr[40-100].dll. Those particular DLLs aren't shipped with >>>>> Windows, and if you depend on them you MUST ship them. >>>>> >>>>> >>>>> Better though would be to statically link the CRT for the 64-bit VM, >>>>> using /MT. That would also seem to be good advice for the 32-bit VM, >>>>> to remove the dependency on the system msvcrt.dll. Statically >>>>> linking the 64-bit VM will also significantly reduce the total size >>>>> of the application, since I imagine VW only uses a tiny fraction of >>>>> the whole msvcrt100.dll. >>>>> >>>>> >>>>> Cheers, >>>>> >>>>> Steve >>>>> >>>>> >>>>> >>>>> From: [hidden email] [mailto:vw-dev- >> [hidden email]] >>>>> On Behalf Of Alan Knight >>>>> Sent: 11. helmikuuta 2011 1:34 >>>>> To: [hidden email] >>>>> Subject: Re: vw7.8 64-bit on windows error >>>>> >>>>> >>>>> I don't think we have statically linked the MSVCR libraries in >>>>> previous versions, at least not for a very long time. I also don't >>>>> think that those libraries are part of the Windows installs, but >>>>> they tended to be there if you'd installed anything at all. And >>>>> possibly if the operating system included programs that were built >>>>> with those compilers they would be for practical purposes included. >>>>> The difference in this case is, I suspect, that people have fewer >>>>> things installed that are 64-bit applications, and the compiler is newer. >>>>> >>>>> It is not needed on 32-bit installations, because we are for the >>>>> moment still using an older compiler version for the 32-bit >>>>> versions, partly because of that dependency. Building the 64-bit >>>>> versions required the use of the more recent compiler. 32-bit >>>>> versions appear to my untrained eye to require MSVCRT.DLL with no >>>>> version number embedded in the name. I don't believe it makes any >> difference between visual.exe and vwnt.exe. >>>>> >>>>> It's possible that we really ought to be installing it, but it is >>>>> not something we've ever done in the past and it does not seem to >>>>> have previously been an issue. >>>>> >>>>> >>>>> >>>>> In earlier versions, the necessary parts of the MSVCR library have >>>>> been statically linked (IIRC), or then the relevant library has been >>>>> part of a normal Windows installation anyway (maybe in IE?). Even >>>>> the Cairo DLL was kindly made by Travis to be statically linked >>>>> rather than require >>>>> MSCVR90.dll: >>>>> >>>>> http://www.parcplace.net/list/vwnc-archive/0910/msg00085.html >>>>> >>>>> Information on static linking and msvcr100.dll is in the last >>>>> message >>>>> here: >>>>> >>>>> >> http://social.msdn.microsoft.com/Forums/en/vssetup/thread/6891665f-f >>>>> d83- >>>>> 426a-9d73-69d6d7e171a3 >>>>> >>>>> >>>>> As Martin said, a vendor using a redistributable dynamically linked >>>>> library like this is expected to ship it as part of their installer >>>>> - as can be seen from e.g. InstallShield, which comes with a wide >>>>> range of redistributables that install builders can add to their >>>>> install. It's also what Microsoft says to do (IIUC): >>>>> >>>>> http://msdn.microsoft.com/en-us/library/ms235299.aspx >>>>> >>>>> "If you use a merge module that contains a Visual C++ DLL, you must >>>>> include it in the Windows Installer package (or similar installation >>>>> package) that you are using to deploy the application" >>>>> >>>>> >>>>> Of course, all this is just for what Cincom should do when providing >>>>> their product, if that product were just an application. Given the >>>>> product in this case is a development environment, Cincom should >>>>> also provide automation and/or instructions for developers to create >>>>> and deploy their own products - including any necessary >> redistributables. >>>>> Otherwise end users are going to be reporting that the application >>>>> doesn't work, and developers aren't going to understand why (and >>>>> presumably Cincom isn't going to get any royalties in that case!). >>>>> >>>>> >>>>> Is msvcr100.dll also needed on 32-bit VW 7.8 installations on Windows? >>>>> Does it make a difference if we use the monolithic visual.exe VM or >>>>> the split .exe+.dll VM? >>>>> >>>>> >>>>> Cheers, >>>>> >>>>> Steve >>>>> >>>>> >>>>> >>>>> ________________________________ >>>>> >>>>> From: [hidden email] on behalf of Alan Knight >>>>> Sent: Thu 10/02/2011 19:55 >>>>> To: Martin McClure >>>>> Cc: [hidden email] >>>>> Subject: Re: vw7.8 64-bit on windows error >>>>> >>>>> >>>>> That isn't something we've done in the past. I think that typically >>>>> those libraries end up installed quite widely as soon as you've >>>>> installed anything. And it would be a bit tricky, in that it >>>>> wouldn't be integrated with our installation mechanisms. I think >>>>> about the best we could do at this point would be to include a copy >>>>> on the CD or download and people would have to install it >>>>> themselves. We can also look into trying to do something in the next >>>>> release when we expect to have Win64 as fully supported, but it's quite >> late to try much for this one. >>>>> >>>>> On 2011-02-10 12:09 AM, Martin McClure wrote: >>>>>> >>>>>> On 02/09/11 11:11, Alan Knight wrote: >>>>>>> >>>>>>> you need to install the appropriate MS runtime for the most recent >>>>>>> compiler. >>>>>> >>>>>> I'd gotten the impression that Microsoft's intent is that when an >>>>>> application requires a particular version of the MSVCR library, the >>>>>> application vendor should ship that MSVCR library along with the >>>>>> application. >>>>>> >>>>>> Would it be possible to include that with the Windows install? >>>>>> >>>>>> Regards, >>>>>> >>>>>> -Martin >>>>> >>>>> >>>>> -- >>>>> Alan Knight [|], Engineering Manager, Cincom Smalltalk >>>>> [hidden email] [hidden email] http://www.cincomsmalltalk.com >>>>> <http://www.cincomsmalltalk.com/> >>>>> >>>>> >>>>> >>>>> >>> >> >> _______________________________________________ >> vwnc mailing list >> [hidden email] >> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc >> > > > _______________________________________________ > vwnc mailing list > [hidden email] > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc James Robertson http://www.jarober.com [hidden email] _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
|
|
David Buck James Robertson wrote: While I enjoy simple deployments as much as the next guy, I'm not sure how this qualifies as a showstopper. I developed the build tool we use at my current job; when we end up in 7.9, I'll have the change a batch file to copy this file from a known location (a copy will end up being kept with a few other files we need in the image dir) to the deployment directory. Static linking was something that used to be done with database dlls way, way back in the day, and it caused problems - people ended up being stuck on specific revs of the various databases ParcPlace supported. How does adding one file to your install procedure cause that much heartburn? On Jul 15, 2012, at 4:09 AM, Christian Haider wrote: _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: [now vw7.9] msvcr100.dll Re: vw7.8 64-bit on windowserror
|
|
In reply to this post by Christian Haider
Well, I deploy as a single file as documented in the AppDevGuide on page 21-3 and $VISUALWORKS\packaging\win\WindowsPackaging.txt.
I really like that, since I don't need a full installer and my clients just download a zip file, unpack the .exe and put it wherever they like (server directory, desktop or even a USB-stick or CD-ROM) and just run it. With the new DLL regime, I guess, that this deployment strategy is obsolete and one needs to do the full installer dance... (I have not gotten the 7.9 yet, so I don't know if the single file deployment doc section is still in place which would be wrong then...). James - if you have only one file to deploy, any additional file stops the show... Christian > -----Ursprüngliche Nachricht----- > Von: [hidden email] [mailto:[hidden email]] Im > Auftrag von James Robertson > Gesendet: Sonntag, 15. Juli 2012 15:31 > An: VWNC NC > Betreff: Re: [vwnc] [now vw7.9] msvcr100.dll Re: vw7.8 64-bit on > windowserror > > While I enjoy simple deployments as much as the next guy, I'm not sure how > this qualifies as a showstopper. I developed the build tool we use at my > current job; when we end up in 7.9, I'll have the change a batch file to copy > this file from a known location (a copy will end up being kept with a few > other files we need in the image dir) to the deployment directory. > > Static linking was something that used to be done with database dlls way, > way back in the day, and it caused problems - people ended up being stuck > on specific revs of the various databases ParcPlace supported. > > How does adding one file to your install procedure cause that much > heartburn? > > On Jul 15, 2012, at 4:09 AM, Christian Haider wrote: > > > Yes, this is going to be a show-stopper for using VW 7.9 for me as > > well :-( > > > > But since linking the DLLs statically to the VMs for Windows needs to be > done only once, maybe somebody did this and could share the VM with the > community? > > > > I wonder why Cincom is not able to provide such a VM... Is it so hard to do > or are there legal issues involved? > > > > I really hope that there will be a practical solution to this problem without > having to dive into C land to figure out how to do that myself... > > > > Christian > > > >> -----Ursprüngliche Nachricht----- > >> Von: [hidden email] [mailto:[hidden email]] Im > >> Auftrag von Carl Gundel > >> Gesendet: Sonntag, 15. Juli 2012 06:31 > >> An: VWNC List > >> Betreff: [vwnc] [now vw7.9] msvcr100.dll Re: vw7.8 64-bit on windows > >> error > >> > >>> From the 7.9 release notes: > >> > >> "Windows OE DLL Requirement > >> Due to a compiler upgrade, the Windows VMs require that msvcr100.dll > >> be installed in its proper location (System32 or SysWOW64).If this > >> DLL is not already installed, the installer installs and runs a > >> program (VisualWorks32bitDLLPrereqs, and VisualWorks64bitDLLPrereqs > >> on 64-bit > >> systems) that installs the DLL(s) and registers VisualWorks' interest in > them. > >> After installation, an information screen tells you this has been > >> done. If you uninstall this program, VisualWorks is deregistered for > >> it, and the DLL is removed if no other program has an interest. > >> When deploying an application with the VM, you are responsible for > >> ensuring that this file is present on the target system." > >> > >> So, this is now required for 32-bit VisualWorks on Windows also? > >> > >> This is going to be very, very inconvenient for me. The single file > >> VM and the ability to embed the image in the VM are one of the > >> reasons I chose VisualWorks. Up to this point I have not needed any > >> extra libraries and this is very important to me and to my customers. > >> The msvcr100.dll throws a real monkey wrench into things for me. I > >> hope that Cincom will decide to statically link whatever functions it > >> needs from this DLL going forward. I may be forced to stick with 7.8 > otherwise. > >> > >> -Carl Gundel > >> http://www.libertybasic.com > >> http://www.runbasic.com > >> > >> On Sun, Feb 20, 2011 at 10:29 AM, Alan Knight <[hidden email]> wrote: > >>> > >>> Yes, this is expected. We'll need to do something about that, but > >>> for 7.8, where win64 is in preview, I think it's likely to remain > >>> and we'll sort out the various possibilities with a bit more time to > consider. > >>> > >>> > >>> On 11-02-20 6:36 AM, Steffen Märcker wrote: > >>>> > >>>> > >>>> I've just attempted to start the win64 vm on Windows 7 Prof. 64 Bit > >>>> and got the message to install msvcr100.dll too. Do I understand > >>>> this thread right that this is actually expected? > >>>> > >>>> Regards, Steffen > >>>> > >>>> > >>>> Am 11.02.2011, 11:17 Uhr, schrieb Steven Kelly > <[hidden email]>: > >>>> > >>>>> I just went through all VW monolithic VMs from 2.0 to 7.7.1 with > >>>>> Dependency Walker: > >>>>> > >>>>> 2.0 and 2.5 statically linked any functions they called from > >>>>> msvcrt.dll > >>>>> > >>>>> 3.0 dynamically linked msvcrt40.dll, but 3.0b already changed that > >>>>> to just msvcrt.dll. > >>>>> > >>>>> 5i.3 - 7.7.1 have all dynamically linked msvcrt.dll, which has > >>>>> been an obligatory part of standard Windows installs for over a > >>>>> decade > >>>>> > <http://en.wikipedia.org/wiki/Microsoft_Windows_library_files#Msvc > >>>>> rt > >>>>> .dll > >>>>>> > >>>>>> (Windows 2000 on), in Windows\system32 (and before that part of a > >>>>> > >>>>> normal Windows install since at least Windows 95 > >>>>> <http://support.microsoft.com/kb/895959> ). > >>>>> > >>>>> > >>>>> There's a big difference > >>>>> <http://msdn.microsoft.com/en- > >> us/library/abx4dbyh(VS.71).aspx#CodeSp > >>>>> ippe > >>>>> t0> between msvcrt.dll (a system file) and msvcr[71-100].dll. The > >>>>> former is guaranteed to be found (although you have no control > >>>>> over the exact version), the latter must be installed with your > application. > >>>>> > >>>>> > >>>>> In theory you shouldn't rely on the system msvcrt.dll, since it > >>>>> will be a different version from what you used in your own > >>>>> testing, but in practice for VW this seems to have worked well. I > >>>>> imagine VW's reliance is pretty generic and stable, so it's been > >>>>> more likely that things improved when MS shipped an update to > >>>>> msvcrt.dll, than that things would break. XP SP2 was the > >>>>> exception, as the significant changes it introduced caused > >>>>> problems in many applications. It looks like Microsoft are moving > >>>>> away from allowing 3rd party apps to dynamically link to the > >>>>> system msvcrt.dll, so Cincom should stop too. There's a good > >>>>> discussion > >>>>> <http://stackoverflow.com/questions/1073509/should-i-redistribute- > >>>>> ms > >>>>> vcrt > >>>>> -dll-with-my-application> on the pros and cons on StackOverflow. > >>>>> > >>>>> > >>>>> So, with the exception of 3.0 (which was corrected in 3.0b), no > >>>>> previous VM has dynamically depended on a particular > >>>>> msvcr[40-100].dll. Those particular DLLs aren't shipped with > >>>>> Windows, and if you depend on them you MUST ship them. > >>>>> > >>>>> > >>>>> Better though would be to statically link the CRT for the 64-bit > >>>>> VM, using /MT. That would also seem to be good advice for the > >>>>> 32-bit VM, to remove the dependency on the system msvcrt.dll. > >>>>> Statically linking the 64-bit VM will also significantly reduce > >>>>> the total size of the application, since I imagine VW only uses a > >>>>> tiny fraction of the whole msvcrt100.dll. > >>>>> > >>>>> > >>>>> Cheers, > >>>>> > >>>>> Steve > >>>>> > >>>>> > >>>>> > >>>>> From: [hidden email] [mailto:vw-dev- > >> [hidden email]] > >>>>> On Behalf Of Alan Knight > >>>>> Sent: 11. helmikuuta 2011 1:34 > >>>>> To: [hidden email] > >>>>> Subject: Re: vw7.8 64-bit on windows error > >>>>> > >>>>> > >>>>> I don't think we have statically linked the MSVCR libraries in > >>>>> previous versions, at least not for a very long time. I also don't > >>>>> think that those libraries are part of the Windows installs, but > >>>>> they tended to be there if you'd installed anything at all. And > >>>>> possibly if the operating system included programs that were built > >>>>> with those compilers they would be for practical purposes included. > >>>>> The difference in this case is, I suspect, that people have fewer > >>>>> things installed that are 64-bit applications, and the compiler is newer. > >>>>> > >>>>> It is not needed on 32-bit installations, because we are for the > >>>>> moment still using an older compiler version for the 32-bit > >>>>> versions, partly because of that dependency. Building the 64-bit > >>>>> versions required the use of the more recent compiler. 32-bit > >>>>> versions appear to my untrained eye to require MSVCRT.DLL with no > >>>>> version number embedded in the name. I don't believe it makes any > >> difference between visual.exe and vwnt.exe. > >>>>> > >>>>> It's possible that we really ought to be installing it, but it is > >>>>> not something we've ever done in the past and it does not seem to > >>>>> have previously been an issue. > >>>>> > >>>>> > >>>>> > >>>>> In earlier versions, the necessary parts of the MSVCR library have > >>>>> been statically linked (IIRC), or then the relevant library has > >>>>> been part of a normal Windows installation anyway (maybe in IE?). > >>>>> Even the Cairo DLL was kindly made by Travis to be statically > >>>>> linked rather than require > >>>>> MSCVR90.dll: > >>>>> > >>>>> http://www.parcplace.net/list/vwnc-archive/0910/msg00085.html > >>>>> > >>>>> Information on static linking and msvcr100.dll is in the last > >>>>> message > >>>>> here: > >>>>> > >>>>> > >> http://social.msdn.microsoft.com/Forums/en/vssetup/thread/6891665f-f > >>>>> d83- > >>>>> 426a-9d73-69d6d7e171a3 > >>>>> > >>>>> > >>>>> As Martin said, a vendor using a redistributable dynamically > >>>>> linked library like this is expected to ship it as part of their > >>>>> installer > >>>>> - as can be seen from e.g. InstallShield, which comes with a wide > >>>>> range of redistributables that install builders can add to their > >>>>> install. It's also what Microsoft says to do (IIUC): > >>>>> > >>>>> http://msdn.microsoft.com/en-us/library/ms235299.aspx > >>>>> > >>>>> "If you use a merge module that contains a Visual C++ DLL, you > >>>>> must include it in the Windows Installer package (or similar > >>>>> installation > >>>>> package) that you are using to deploy the application" > >>>>> > >>>>> > >>>>> Of course, all this is just for what Cincom should do when > >>>>> providing their product, if that product were just an application. > >>>>> Given the product in this case is a development environment, > >>>>> Cincom should also provide automation and/or instructions for > >>>>> developers to create and deploy their own products - including any > >>>>> necessary > >> redistributables. > >>>>> Otherwise end users are going to be reporting that the application > >>>>> doesn't work, and developers aren't going to understand why (and > >>>>> presumably Cincom isn't going to get any royalties in that case!). > >>>>> > >>>>> > >>>>> Is msvcr100.dll also needed on 32-bit VW 7.8 installations on > Windows? > >>>>> Does it make a difference if we use the monolithic visual.exe VM > >>>>> or the split .exe+.dll VM? > >>>>> > >>>>> > >>>>> Cheers, > >>>>> > >>>>> Steve > >>>>> > >>>>> > >>>>> > >>>>> ________________________________ > >>>>> > >>>>> From: [hidden email] on behalf of Alan Knight > >>>>> Sent: Thu 10/02/2011 19:55 > >>>>> To: Martin McClure > >>>>> Cc: [hidden email] > >>>>> Subject: Re: vw7.8 64-bit on windows error > >>>>> > >>>>> > >>>>> That isn't something we've done in the past. I think that > >>>>> typically those libraries end up installed quite widely as soon as > >>>>> you've installed anything. And it would be a bit tricky, in that > >>>>> it wouldn't be integrated with our installation mechanisms. I > >>>>> think about the best we could do at this point would be to include > >>>>> a copy on the CD or download and people would have to install it > >>>>> themselves. We can also look into trying to do something in the > >>>>> next release when we expect to have Win64 as fully supported, but > >>>>> it's quite > >> late to try much for this one. > >>>>> > >>>>> On 2011-02-10 12:09 AM, Martin McClure wrote: > >>>>>> > >>>>>> On 02/09/11 11:11, Alan Knight wrote: > >>>>>>> > >>>>>>> you need to install the appropriate MS runtime for the most > >>>>>>> recent compiler. > >>>>>> > >>>>>> I'd gotten the impression that Microsoft's intent is that when an > >>>>>> application requires a particular version of the MSVCR library, > >>>>>> the application vendor should ship that MSVCR library along with > >>>>>> the application. > >>>>>> > >>>>>> Would it be possible to include that with the Windows install? > >>>>>> > >>>>>> Regards, > >>>>>> > >>>>>> -Martin > >>>>> > >>>>> > >>>>> -- > >>>>> Alan Knight [|], Engineering Manager, Cincom Smalltalk > >>>>> [hidden email] [hidden email] > http://www.cincomsmalltalk.com > >>>>> <http://www.cincomsmalltalk.com/> > >>>>> > >>>>> > >>>>> > >>>>> > >>> > >> > >> _______________________________________________ > >> vwnc mailing list > >> [hidden email] > >> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > >> > > > > > > _______________________________________________ > > vwnc mailing list > > [hidden email] > > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > > James Robertson > http://www.jarober.com > [hidden email] > > > > > _______________________________________________ > vwnc mailing list > [hidden email] > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: [now vw7.9] msvcr100.dll Re: vw7.8 64-bit on windowserror
|
|
This is similar to my situation. My customers have been waiting for a single file deployment mechanism for Liberty BASIC apps for a very long time, and this takes me one step away from it again. So if Cincom can solve this problem by statically linking the functions needed I can only say.
Please, please, please do it! James, so it doesn't really matter to you one way or the other, just as small deliverables don't seem to matter to you, but it does matter to some customers, believe it or not. I chose VW in part because external libraries were not required. The tools should be as flexible as possible. Suddenly requiring a DLL that wasn't required before can be a burden to some development projects. Thanks, -Carl Gundel Liberty BASIC for Windows - http://www.libertybasic.com Run BASIC, easy web programming - http://www.runbasic.com On Jul 15, 2012, at 10:22 AM, "Christian Haider" <[hidden email]> wrote: > Well, I deploy as a single file as documented in the AppDevGuide on page 21-3 and $VISUALWORKS\packaging\win\WindowsPackaging.txt. > > I really like that, since I don't need a full installer and my clients just download a zip file, unpack the .exe and put it wherever they like (server directory, desktop or even a USB-stick or CD-ROM) and just run it. > > With the new DLL regime, I guess, that this deployment strategy is obsolete and one needs to do the full installer dance... (I have not gotten the 7.9 yet, so I don't know if the single file deployment doc section is still in place which would be wrong then...). > > James - if you have only one file to deploy, any additional file stops the show... > > Christian > >> -----Ursprüngliche Nachricht----- >> Von: [hidden email] [mailto:[hidden email]] Im >> Auftrag von James Robertson >> Gesendet: Sonntag, 15. Juli 2012 15:31 >> An: VWNC NC >> Betreff: Re: [vwnc] [now vw7.9] msvcr100.dll Re: vw7.8 64-bit on >> windowserror >> >> While I enjoy simple deployments as much as the next guy, I'm not sure how >> this qualifies as a showstopper. I developed the build tool we use at my >> current job; when we end up in 7.9, I'll have the change a batch file to copy >> this file from a known location (a copy will end up being kept with a few >> other files we need in the image dir) to the deployment directory. >> >> Static linking was something that used to be done with database dlls way, >> way back in the day, and it caused problems - people ended up being stuck >> on specific revs of the various databases ParcPlace supported. >> >> How does adding one file to your install procedure cause that much >> heartburn? >> >> On Jul 15, 2012, at 4:09 AM, Christian Haider wrote: >> >>> Yes, this is going to be a show-stopper for using VW 7.9 for me as >>> well :-( >>> >>> But since linking the DLLs statically to the VMs for Windows needs to be >> done only once, maybe somebody did this and could share the VM with the >> community? >>> >>> I wonder why Cincom is not able to provide such a VM... Is it so hard to do >> or are there legal issues involved? >>> >>> I really hope that there will be a practical solution to this problem without >> having to dive into C land to figure out how to do that myself... >>> >>> Christian >>> >>>> -----Ursprüngliche Nachricht----- >>>> Von: [hidden email] [mailto:[hidden email]] Im >>>> Auftrag von Carl Gundel >>>> Gesendet: Sonntag, 15. Juli 2012 06:31 >>>> An: VWNC List >>>> Betreff: [vwnc] [now vw7.9] msvcr100.dll Re: vw7.8 64-bit on windows >>>> error >>>> >>>>> From the 7.9 release notes: >>>> >>>> "Windows OE DLL Requirement >>>> Due to a compiler upgrade, the Windows VMs require that msvcr100.dll >>>> be installed in its proper location (System32 or SysWOW64).If this >>>> DLL is not already installed, the installer installs and runs a >>>> program (VisualWorks32bitDLLPrereqs, and VisualWorks64bitDLLPrereqs >>>> on 64-bit >>>> systems) that installs the DLL(s) and registers VisualWorks' interest in >> them. >>>> After installation, an information screen tells you this has been >>>> done. If you uninstall this program, VisualWorks is deregistered for >>>> it, and the DLL is removed if no other program has an interest. >>>> When deploying an application with the VM, you are responsible for >>>> ensuring that this file is present on the target system." >>>> >>>> So, this is now required for 32-bit VisualWorks on Windows also? >>>> >>>> This is going to be very, very inconvenient for me. The single file >>>> VM and the ability to embed the image in the VM are one of the >>>> reasons I chose VisualWorks. Up to this point I have not needed any >>>> extra libraries and this is very important to me and to my customers. >>>> The msvcr100.dll throws a real monkey wrench into things for me. I >>>> hope that Cincom will decide to statically link whatever functions it >>>> needs from this DLL going forward. I may be forced to stick with 7.8 >> otherwise. >>>> >>>> -Carl Gundel >>>> http://www.libertybasic.com >>>> http://www.runbasic.com >>>> >>>> On Sun, Feb 20, 2011 at 10:29 AM, Alan Knight <[hidden email]> wrote: >>>>> >>>>> Yes, this is expected. We'll need to do something about that, but >>>>> for 7.8, where win64 is in preview, I think it's likely to remain >>>>> and we'll sort out the various possibilities with a bit more time to >> consider. >>>>> >>>>> >>>>> On 11-02-20 6:36 AM, Steffen Märcker wrote: >>>>>> >>>>>> >>>>>> I've just attempted to start the win64 vm on Windows 7 Prof. 64 Bit >>>>>> and got the message to install msvcr100.dll too. Do I understand >>>>>> this thread right that this is actually expected? >>>>>> >>>>>> Regards, Steffen >>>>>> >>>>>> >>>>>> Am 11.02.2011, 11:17 Uhr, schrieb Steven Kelly >> <[hidden email]>: >>>>>> >>>>>>> I just went through all VW monolithic VMs from 2.0 to 7.7.1 with >>>>>>> Dependency Walker: >>>>>>> >>>>>>> 2.0 and 2.5 statically linked any functions they called from >>>>>>> msvcrt.dll >>>>>>> >>>>>>> 3.0 dynamically linked msvcrt40.dll, but 3.0b already changed that >>>>>>> to just msvcrt.dll. >>>>>>> >>>>>>> 5i.3 - 7.7.1 have all dynamically linked msvcrt.dll, which has >>>>>>> been an obligatory part of standard Windows installs for over a >>>>>>> decade >>>>>>> >> <http://en.wikipedia.org/wiki/Microsoft_Windows_library_files#Msvc >>>>>>> rt >>>>>>> .dll >>>>>>>> >>>>>>>> (Windows 2000 on), in Windows\system32 (and before that part of a >>>>>>> >>>>>>> normal Windows install since at least Windows 95 >>>>>>> <http://support.microsoft.com/kb/895959> ). >>>>>>> >>>>>>> >>>>>>> There's a big difference >>>>>>> <http://msdn.microsoft.com/en- >>>> us/library/abx4dbyh(VS.71).aspx#CodeSp >>>>>>> ippe >>>>>>> t0> between msvcrt.dll (a system file) and msvcr[71-100].dll. The >>>>>>> former is guaranteed to be found (although you have no control >>>>>>> over the exact version), the latter must be installed with your >> application. >>>>>>> >>>>>>> >>>>>>> In theory you shouldn't rely on the system msvcrt.dll, since it >>>>>>> will be a different version from what you used in your own >>>>>>> testing, but in practice for VW this seems to have worked well. I >>>>>>> imagine VW's reliance is pretty generic and stable, so it's been >>>>>>> more likely that things improved when MS shipped an update to >>>>>>> msvcrt.dll, than that things would break. XP SP2 was the >>>>>>> exception, as the significant changes it introduced caused >>>>>>> problems in many applications. It looks like Microsoft are moving >>>>>>> away from allowing 3rd party apps to dynamically link to the >>>>>>> system msvcrt.dll, so Cincom should stop too. There's a good >>>>>>> discussion >>>>>>> <http://stackoverflow.com/questions/1073509/should-i-redistribute- >>>>>>> ms >>>>>>> vcrt >>>>>>> -dll-with-my-application> on the pros and cons on StackOverflow. >>>>>>> >>>>>>> >>>>>>> So, with the exception of 3.0 (which was corrected in 3.0b), no >>>>>>> previous VM has dynamically depended on a particular >>>>>>> msvcr[40-100].dll. Those particular DLLs aren't shipped with >>>>>>> Windows, and if you depend on them you MUST ship them. >>>>>>> >>>>>>> >>>>>>> Better though would be to statically link the CRT for the 64-bit >>>>>>> VM, using /MT. That would also seem to be good advice for the >>>>>>> 32-bit VM, to remove the dependency on the system msvcrt.dll. >>>>>>> Statically linking the 64-bit VM will also significantly reduce >>>>>>> the total size of the application, since I imagine VW only uses a >>>>>>> tiny fraction of the whole msvcrt100.dll. >>>>>>> >>>>>>> >>>>>>> Cheers, >>>>>>> >>>>>>> Steve >>>>>>> >>>>>>> >>>>>>> >>>>>>> From: [hidden email] [mailto:vw-dev- >>>> [hidden email]] >>>>>>> On Behalf Of Alan Knight >>>>>>> Sent: 11. helmikuuta 2011 1:34 >>>>>>> To: [hidden email] >>>>>>> Subject: Re: vw7.8 64-bit on windows error >>>>>>> >>>>>>> >>>>>>> I don't think we have statically linked the MSVCR libraries in >>>>>>> previous versions, at least not for a very long time. I also don't >>>>>>> think that those libraries are part of the Windows installs, but >>>>>>> they tended to be there if you'd installed anything at all. And >>>>>>> possibly if the operating system included programs that were built >>>>>>> with those compilers they would be for practical purposes included. >>>>>>> The difference in this case is, I suspect, that people have fewer >>>>>>> things installed that are 64-bit applications, and the compiler is newer. >>>>>>> >>>>>>> It is not needed on 32-bit installations, because we are for the >>>>>>> moment still using an older compiler version for the 32-bit >>>>>>> versions, partly because of that dependency. Building the 64-bit >>>>>>> versions required the use of the more recent compiler. 32-bit >>>>>>> versions appear to my untrained eye to require MSVCRT.DLL with no >>>>>>> version number embedded in the name. I don't believe it makes any >>>> difference between visual.exe and vwnt.exe. >>>>>>> >>>>>>> It's possible that we really ought to be installing it, but it is >>>>>>> not something we've ever done in the past and it does not seem to >>>>>>> have previously been an issue. >>>>>>> >>>>>>> >>>>>>> >>>>>>> In earlier versions, the necessary parts of the MSVCR library have >>>>>>> been statically linked (IIRC), or then the relevant library has >>>>>>> been part of a normal Windows installation anyway (maybe in IE?). >>>>>>> Even the Cairo DLL was kindly made by Travis to be statically >>>>>>> linked rather than require >>>>>>> MSCVR90.dll: >>>>>>> >>>>>>> http://www.parcplace.net/list/vwnc-archive/0910/msg00085.html >>>>>>> >>>>>>> Information on static linking and msvcr100.dll is in the last >>>>>>> message >>>>>>> here: >>>>>>> >>>>>>> >>>> http://social.msdn.microsoft.com/Forums/en/vssetup/thread/6891665f-f >>>>>>> d83- >>>>>>> 426a-9d73-69d6d7e171a3 >>>>>>> >>>>>>> >>>>>>> As Martin said, a vendor using a redistributable dynamically >>>>>>> linked library like this is expected to ship it as part of their >>>>>>> installer >>>>>>> - as can be seen from e.g. InstallShield, which comes with a wide >>>>>>> range of redistributables that install builders can add to their >>>>>>> install. It's also what Microsoft says to do (IIUC): >>>>>>> >>>>>>> http://msdn.microsoft.com/en-us/library/ms235299.aspx >>>>>>> >>>>>>> "If you use a merge module that contains a Visual C++ DLL, you >>>>>>> must include it in the Windows Installer package (or similar >>>>>>> installation >>>>>>> package) that you are using to deploy the application" >>>>>>> >>>>>>> >>>>>>> Of course, all this is just for what Cincom should do when >>>>>>> providing their product, if that product were just an application. >>>>>>> Given the product in this case is a development environment, >>>>>>> Cincom should also provide automation and/or instructions for >>>>>>> developers to create and deploy their own products - including any >>>>>>> necessary >>>> redistributables. >>>>>>> Otherwise end users are going to be reporting that the application >>>>>>> doesn't work, and developers aren't going to understand why (and >>>>>>> presumably Cincom isn't going to get any royalties in that case!). >>>>>>> >>>>>>> >>>>>>> Is msvcr100.dll also needed on 32-bit VW 7.8 installations on >> Windows? >>>>>>> Does it make a difference if we use the monolithic visual.exe VM >>>>>>> or the split .exe+.dll VM? >>>>>>> >>>>>>> >>>>>>> Cheers, >>>>>>> >>>>>>> Steve >>>>>>> >>>>>>> >>>>>>> >>>>>>> ________________________________ >>>>>>> >>>>>>> From: [hidden email] on behalf of Alan Knight >>>>>>> Sent: Thu 10/02/2011 19:55 >>>>>>> To: Martin McClure >>>>>>> Cc: [hidden email] >>>>>>> Subject: Re: vw7.8 64-bit on windows error >>>>>>> >>>>>>> >>>>>>> That isn't something we've done in the past. I think that >>>>>>> typically those libraries end up installed quite widely as soon as >>>>>>> you've installed anything. And it would be a bit tricky, in that >>>>>>> it wouldn't be integrated with our installation mechanisms. I >>>>>>> think about the best we could do at this point would be to include >>>>>>> a copy on the CD or download and people would have to install it >>>>>>> themselves. We can also look into trying to do something in the >>>>>>> next release when we expect to have Win64 as fully supported, but >>>>>>> it's quite >>>> late to try much for this one. >>>>>>> >>>>>>> On 2011-02-10 12:09 AM, Martin McClure wrote: >>>>>>>> >>>>>>>> On 02/09/11 11:11, Alan Knight wrote: >>>>>>>>> >>>>>>>>> you need to install the appropriate MS runtime for the most >>>>>>>>> recent compiler. >>>>>>>> >>>>>>>> I'd gotten the impression that Microsoft's intent is that when an >>>>>>>> application requires a particular version of the MSVCR library, >>>>>>>> the application vendor should ship that MSVCR library along with >>>>>>>> the application. >>>>>>>> >>>>>>>> Would it be possible to include that with the Windows install? >>>>>>>> >>>>>>>> Regards, >>>>>>>> >>>>>>>> -Martin >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Alan Knight [|], Engineering Manager, Cincom Smalltalk >>>>>>> [hidden email] [hidden email] >> http://www.cincomsmalltalk.com >>>>>>> <http://www.cincomsmalltalk.com/> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>> >>>> >>>> _______________________________________________ >>>> vwnc mailing list >>>> [hidden email] >>>> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc >>>> >>> >>> >>> _______________________________________________ >>> vwnc mailing list >>> [hidden email] >>> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc >> >> James Robertson >> http://www.jarober.com >> [hidden email] >> >> >> >> >> _______________________________________________ >> vwnc mailing list >> [hidden email] >> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc >> > > > _______________________________________________ > vwnc mailing list > [hidden email] > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
|
|
In reply to this post by Christian Haider
For BottomFeeder (many moons ago now), I started using the Nullsoft installer. It was very, very easy to script. Unless you have a real need to go insane, I'd avoid the MS installer....
On Jul 15, 2012, at 10:22 AM, Christian Haider wrote: > Well, I deploy as a single file as documented in the AppDevGuide on page 21-3 and $VISUALWORKS\packaging\win\WindowsPackaging.txt. > > I really like that, since I don't need a full installer and my clients just download a zip file, unpack the .exe and put it wherever they like (server directory, desktop or even a USB-stick or CD-ROM) and just run it. > > With the new DLL regime, I guess, that this deployment strategy is obsolete and one needs to do the full installer dance... (I have not gotten the 7.9 yet, so I don't know if the single file deployment doc section is still in place which would be wrong then...). > > James - if you have only one file to deploy, any additional file stops the show... > > Christian > >> -----Ursprüngliche Nachricht----- >> Von: [hidden email] [mailto:[hidden email]] Im >> Auftrag von James Robertson >> Gesendet: Sonntag, 15. Juli 2012 15:31 >> An: VWNC NC >> Betreff: Re: [vwnc] [now vw7.9] msvcr100.dll Re: vw7.8 64-bit on >> windowserror >> >> While I enjoy simple deployments as much as the next guy, I'm not sure how >> this qualifies as a showstopper. I developed the build tool we use at my >> current job; when we end up in 7.9, I'll have the change a batch file to copy >> this file from a known location (a copy will end up being kept with a few >> other files we need in the image dir) to the deployment directory. >> >> Static linking was something that used to be done with database dlls way, >> way back in the day, and it caused problems - people ended up being stuck >> on specific revs of the various databases ParcPlace supported. >> >> How does adding one file to your install procedure cause that much >> heartburn? >> >> On Jul 15, 2012, at 4:09 AM, Christian Haider wrote: >> >>> Yes, this is going to be a show-stopper for using VW 7.9 for me as >>> well :-( >>> >>> But since linking the DLLs statically to the VMs for Windows needs to be >> done only once, maybe somebody did this and could share the VM with the >> community? >>> >>> I wonder why Cincom is not able to provide such a VM... Is it so hard to do >> or are there legal issues involved? >>> >>> I really hope that there will be a practical solution to this problem without >> having to dive into C land to figure out how to do that myself... >>> >>> Christian >>> >>>> -----Ursprüngliche Nachricht----- >>>> Von: [hidden email] [mailto:[hidden email]] Im >>>> Auftrag von Carl Gundel >>>> Gesendet: Sonntag, 15. Juli 2012 06:31 >>>> An: VWNC List >>>> Betreff: [vwnc] [now vw7.9] msvcr100.dll Re: vw7.8 64-bit on windows >>>> error >>>> >>>>> From the 7.9 release notes: >>>> >>>> "Windows OE DLL Requirement >>>> Due to a compiler upgrade, the Windows VMs require that msvcr100.dll >>>> be installed in its proper location (System32 or SysWOW64).If this >>>> DLL is not already installed, the installer installs and runs a >>>> program (VisualWorks32bitDLLPrereqs, and VisualWorks64bitDLLPrereqs >>>> on 64-bit >>>> systems) that installs the DLL(s) and registers VisualWorks' interest in >> them. >>>> After installation, an information screen tells you this has been >>>> done. If you uninstall this program, VisualWorks is deregistered for >>>> it, and the DLL is removed if no other program has an interest. >>>> When deploying an application with the VM, you are responsible for >>>> ensuring that this file is present on the target system." >>>> >>>> So, this is now required for 32-bit VisualWorks on Windows also? >>>> >>>> This is going to be very, very inconvenient for me. The single file >>>> VM and the ability to embed the image in the VM are one of the >>>> reasons I chose VisualWorks. Up to this point I have not needed any >>>> extra libraries and this is very important to me and to my customers. >>>> The msvcr100.dll throws a real monkey wrench into things for me. I >>>> hope that Cincom will decide to statically link whatever functions it >>>> needs from this DLL going forward. I may be forced to stick with 7.8 >> otherwise. >>>> >>>> -Carl Gundel >>>> http://www.libertybasic.com >>>> http://www.runbasic.com >>>> >>>> On Sun, Feb 20, 2011 at 10:29 AM, Alan Knight <[hidden email]> wrote: >>>>> >>>>> Yes, this is expected. We'll need to do something about that, but >>>>> for 7.8, where win64 is in preview, I think it's likely to remain >>>>> and we'll sort out the various possibilities with a bit more time to >> consider. >>>>> >>>>> >>>>> On 11-02-20 6:36 AM, Steffen Märcker wrote: >>>>>> >>>>>> >>>>>> I've just attempted to start the win64 vm on Windows 7 Prof. 64 Bit >>>>>> and got the message to install msvcr100.dll too. Do I understand >>>>>> this thread right that this is actually expected? >>>>>> >>>>>> Regards, Steffen >>>>>> >>>>>> >>>>>> Am 11.02.2011, 11:17 Uhr, schrieb Steven Kelly >> <[hidden email]>: >>>>>> >>>>>>> I just went through all VW monolithic VMs from 2.0 to 7.7.1 with >>>>>>> Dependency Walker: >>>>>>> >>>>>>> 2.0 and 2.5 statically linked any functions they called from >>>>>>> msvcrt.dll >>>>>>> >>>>>>> 3.0 dynamically linked msvcrt40.dll, but 3.0b already changed that >>>>>>> to just msvcrt.dll. >>>>>>> >>>>>>> 5i.3 - 7.7.1 have all dynamically linked msvcrt.dll, which has >>>>>>> been an obligatory part of standard Windows installs for over a >>>>>>> decade >>>>>>> >> <http://en.wikipedia.org/wiki/Microsoft_Windows_library_files#Msvc >>>>>>> rt >>>>>>> .dll >>>>>>>> >>>>>>>> (Windows 2000 on), in Windows\system32 (and before that part of a >>>>>>> >>>>>>> normal Windows install since at least Windows 95 >>>>>>> <http://support.microsoft.com/kb/895959> ). >>>>>>> >>>>>>> >>>>>>> There's a big difference >>>>>>> <http://msdn.microsoft.com/en- >>>> us/library/abx4dbyh(VS.71).aspx#CodeSp >>>>>>> ippe >>>>>>> t0> between msvcrt.dll (a system file) and msvcr[71-100].dll. The >>>>>>> former is guaranteed to be found (although you have no control >>>>>>> over the exact version), the latter must be installed with your >> application. >>>>>>> >>>>>>> >>>>>>> In theory you shouldn't rely on the system msvcrt.dll, since it >>>>>>> will be a different version from what you used in your own >>>>>>> testing, but in practice for VW this seems to have worked well. I >>>>>>> imagine VW's reliance is pretty generic and stable, so it's been >>>>>>> more likely that things improved when MS shipped an update to >>>>>>> msvcrt.dll, than that things would break. XP SP2 was the >>>>>>> exception, as the significant changes it introduced caused >>>>>>> problems in many applications. It looks like Microsoft are moving >>>>>>> away from allowing 3rd party apps to dynamically link to the >>>>>>> system msvcrt.dll, so Cincom should stop too. There's a good >>>>>>> discussion >>>>>>> <http://stackoverflow.com/questions/1073509/should-i-redistribute- >>>>>>> ms >>>>>>> vcrt >>>>>>> -dll-with-my-application> on the pros and cons on StackOverflow. >>>>>>> >>>>>>> >>>>>>> So, with the exception of 3.0 (which was corrected in 3.0b), no >>>>>>> previous VM has dynamically depended on a particular >>>>>>> msvcr[40-100].dll. Those particular DLLs aren't shipped with >>>>>>> Windows, and if you depend on them you MUST ship them. >>>>>>> >>>>>>> >>>>>>> Better though would be to statically link the CRT for the 64-bit >>>>>>> VM, using /MT. That would also seem to be good advice for the >>>>>>> 32-bit VM, to remove the dependency on the system msvcrt.dll. >>>>>>> Statically linking the 64-bit VM will also significantly reduce >>>>>>> the total size of the application, since I imagine VW only uses a >>>>>>> tiny fraction of the whole msvcrt100.dll. >>>>>>> >>>>>>> >>>>>>> Cheers, >>>>>>> >>>>>>> Steve >>>>>>> >>>>>>> >>>>>>> >>>>>>> From: [hidden email] [mailto:vw-dev- >>>> [hidden email]] >>>>>>> On Behalf Of Alan Knight >>>>>>> Sent: 11. helmikuuta 2011 1:34 >>>>>>> To: [hidden email] >>>>>>> Subject: Re: vw7.8 64-bit on windows error >>>>>>> >>>>>>> >>>>>>> I don't think we have statically linked the MSVCR libraries in >>>>>>> previous versions, at least not for a very long time. I also don't >>>>>>> think that those libraries are part of the Windows installs, but >>>>>>> they tended to be there if you'd installed anything at all. And >>>>>>> possibly if the operating system included programs that were built >>>>>>> with those compilers they would be for practical purposes included. >>>>>>> The difference in this case is, I suspect, that people have fewer >>>>>>> things installed that are 64-bit applications, and the compiler is newer. >>>>>>> >>>>>>> It is not needed on 32-bit installations, because we are for the >>>>>>> moment still using an older compiler version for the 32-bit >>>>>>> versions, partly because of that dependency. Building the 64-bit >>>>>>> versions required the use of the more recent compiler. 32-bit >>>>>>> versions appear to my untrained eye to require MSVCRT.DLL with no >>>>>>> version number embedded in the name. I don't believe it makes any >>>> difference between visual.exe and vwnt.exe. >>>>>>> >>>>>>> It's possible that we really ought to be installing it, but it is >>>>>>> not something we've ever done in the past and it does not seem to >>>>>>> have previously been an issue. >>>>>>> >>>>>>> >>>>>>> >>>>>>> In earlier versions, the necessary parts of the MSVCR library have >>>>>>> been statically linked (IIRC), or then the relevant library has >>>>>>> been part of a normal Windows installation anyway (maybe in IE?). >>>>>>> Even the Cairo DLL was kindly made by Travis to be statically >>>>>>> linked rather than require >>>>>>> MSCVR90.dll: >>>>>>> >>>>>>> http://www.parcplace.net/list/vwnc-archive/0910/msg00085.html >>>>>>> >>>>>>> Information on static linking and msvcr100.dll is in the last >>>>>>> message >>>>>>> here: >>>>>>> >>>>>>> >>>> http://social.msdn.microsoft.com/Forums/en/vssetup/thread/6891665f-f >>>>>>> d83- >>>>>>> 426a-9d73-69d6d7e171a3 >>>>>>> >>>>>>> >>>>>>> As Martin said, a vendor using a redistributable dynamically >>>>>>> linked library like this is expected to ship it as part of their >>>>>>> installer >>>>>>> - as can be seen from e.g. InstallShield, which comes with a wide >>>>>>> range of redistributables that install builders can add to their >>>>>>> install. It's also what Microsoft says to do (IIUC): >>>>>>> >>>>>>> http://msdn.microsoft.com/en-us/library/ms235299.aspx >>>>>>> >>>>>>> "If you use a merge module that contains a Visual C++ DLL, you >>>>>>> must include it in the Windows Installer package (or similar >>>>>>> installation >>>>>>> package) that you are using to deploy the application" >>>>>>> >>>>>>> >>>>>>> Of course, all this is just for what Cincom should do when >>>>>>> providing their product, if that product were just an application. >>>>>>> Given the product in this case is a development environment, >>>>>>> Cincom should also provide automation and/or instructions for >>>>>>> developers to create and deploy their own products - including any >>>>>>> necessary >>>> redistributables. >>>>>>> Otherwise end users are going to be reporting that the application >>>>>>> doesn't work, and developers aren't going to understand why (and >>>>>>> presumably Cincom isn't going to get any royalties in that case!). >>>>>>> >>>>>>> >>>>>>> Is msvcr100.dll also needed on 32-bit VW 7.8 installations on >> Windows? >>>>>>> Does it make a difference if we use the monolithic visual.exe VM >>>>>>> or the split .exe+.dll VM? >>>>>>> >>>>>>> >>>>>>> Cheers, >>>>>>> >>>>>>> Steve >>>>>>> >>>>>>> >>>>>>> >>>>>>> ________________________________ >>>>>>> >>>>>>> From: [hidden email] on behalf of Alan Knight >>>>>>> Sent: Thu 10/02/2011 19:55 >>>>>>> To: Martin McClure >>>>>>> Cc: [hidden email] >>>>>>> Subject: Re: vw7.8 64-bit on windows error >>>>>>> >>>>>>> >>>>>>> That isn't something we've done in the past. I think that >>>>>>> typically those libraries end up installed quite widely as soon as >>>>>>> you've installed anything. And it would be a bit tricky, in that >>>>>>> it wouldn't be integrated with our installation mechanisms. I >>>>>>> think about the best we could do at this point would be to include >>>>>>> a copy on the CD or download and people would have to install it >>>>>>> themselves. We can also look into trying to do something in the >>>>>>> next release when we expect to have Win64 as fully supported, but >>>>>>> it's quite >>>> late to try much for this one. >>>>>>> >>>>>>> On 2011-02-10 12:09 AM, Martin McClure wrote: >>>>>>>> >>>>>>>> On 02/09/11 11:11, Alan Knight wrote: >>>>>>>>> >>>>>>>>> you need to install the appropriate MS runtime for the most >>>>>>>>> recent compiler. >>>>>>>> >>>>>>>> I'd gotten the impression that Microsoft's intent is that when an >>>>>>>> application requires a particular version of the MSVCR library, >>>>>>>> the application vendor should ship that MSVCR library along with >>>>>>>> the application. >>>>>>>> >>>>>>>> Would it be possible to include that with the Windows install? >>>>>>>> >>>>>>>> Regards, >>>>>>>> >>>>>>>> -Martin >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Alan Knight [|], Engineering Manager, Cincom Smalltalk >>>>>>> [hidden email] [hidden email] >> http://www.cincomsmalltalk.com >>>>>>> <http://www.cincomsmalltalk.com/> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>> >>>> >>>> _______________________________________________ >>>> vwnc mailing list >>>> [hidden email] >>>> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc >>>> >>> >>> >>> _______________________________________________ >>> vwnc mailing list >>> [hidden email] >>> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc >> >> James Robertson >> http://www.jarober.com >> [hidden email] >> >> >> >> >> _______________________________________________ >> vwnc mailing list >> [hidden email] >> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc >> > James Robertson http://www.jarober.com [hidden email] _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: [now vw7.9] msvcr100.dll Re: vw7.8 64-bit on windows error
|
|
In reply to this post by Christian Haider
Dear Carl, Christian, David et al,
the msvcr100.dll does not have to be installed in a system location. For example, the 7.9 VW installer puts it in the system location if it can write to that location. If it cannot, it puts dll in VW's bin/win (and 64bit in bin/win64). Similarly, any app installer can put the dll in the same location as their VM or single file .exe. A local msvcr100.dll acts - as the one used by our VM if no system one is installed on that platform - as a softlink to the system one if present: our VM always uses the system one if present As of VS2010, Microsoft no longer include the dll in its base platforms. This is the change we are responding to - the corresponding prior versions have always been there by default so we never had to install them. (Actually, the dll is there,but hidden, only for MS internal stuff and not promised to remain compatible.) Thus the VS2010 and later dll has to be either - installed in system or - installed locally or - statically linked So the corresponding single-file .exe options are: a) "the full install dance" - almost certainly what you don't want to do if you're using the single file option b) Have your zip expand to YourApp.exe and msvcr100.dll, not just YourApp.exe. As noted, if your customer later installs or upgrade a system msvcr100.dll, it will all still work. (If you want, you can have your installation notes tell the user: "If you can put our msvcr100.dll in the bin and the .exe still works, leave it in the bin - you don't need it." This merely saves them ~750K of space; no other point.) c) Statically-link the dll to the VM: the difference from (b) is that if the user upgrades their platform, you will not upgrade with it, so we're not starting by encouraging this option. We're hoping our customers will say that (b) is OK. (The relevant Microsoft team promise future backward compatibility of the dll in all cases but discovery of major security hole.) HTH Niall Ross >Yes, this is going to be a show-stopper for using VW 7.9 for me as well :-( > >But since linking the DLLs statically to the VMs for Windows needs to be done only once, maybe somebody did this and could share the VM with the community? > >I wonder why Cincom is not able to provide such a VM... Is it so hard to do or are there legal issues involved? > >I really hope that there will be a practical solution to this problem without having to dive into C land to figure out how to do that myself... > >Christian > > > >>-----Ursprüngliche Nachricht----- >>Von: [hidden email] [mailto:[hidden email]] Im >>Auftrag von Carl Gundel >>Gesendet: Sonntag, 15. Juli 2012 06:31 >>An: VWNC List >>Betreff: [vwnc] [now vw7.9] msvcr100.dll Re: vw7.8 64-bit on windows error >> >>>From the 7.9 release notes: >> >>"Windows OE DLL Requirement >>Due to a compiler upgrade, the Windows VMs require that msvcr100.dll be >>installed in its proper location (System32 or SysWOW64).If this DLL is not >>already installed, the installer installs and runs a program >>(VisualWorks32bitDLLPrereqs, and VisualWorks64bitDLLPrereqs on 64-bit >>systems) that installs the DLL(s) and registers VisualWorks' interest in them. >>After installation, an information screen tells you this has been done. If you >>uninstall this program, VisualWorks is deregistered for it, and the DLL is >>removed if no other program has an interest. >>When deploying an application with the VM, you are responsible for ensuring >>that this file is present on the target system." >> >>So, this is now required for 32-bit VisualWorks on Windows also? >> >>This is going to be very, very inconvenient for me. The single file VM and the >>ability to embed the image in the VM are one of the reasons I chose >>VisualWorks. Up to this point I have not needed any extra libraries and this is >>very important to me and to my customers. The msvcr100.dll throws a real >>monkey wrench into things for me. I hope that Cincom will decide to >>statically link whatever functions it needs from this DLL going forward. I may >>be forced to stick with 7.8 otherwise. >> >>-Carl Gundel >>http://www.libertybasic.com >>http://www.runbasic.com >> >>On Sun, Feb 20, 2011 at 10:29 AM, Alan Knight <[hidden email]> wrote: >> >> >>>Yes, this is expected. We'll need to do something about that, but for >>>7.8, where win64 is in preview, I think it's likely to remain and >>>we'll sort out the various possibilities with a bit more time to consider. >>> >>> >>>On 11-02-20 6:36 AM, Steffen Märcker wrote: >>> >>> >>>>I've just attempted to start the win64 vm on Windows 7 Prof. 64 Bit >>>>and got the message to install msvcr100.dll too. Do I understand this >>>>thread right that this is actually expected? >>>> >>>>Regards, Steffen >>>> >>>> >>>>Am 11.02.2011, 11:17 Uhr, schrieb Steven Kelly <[hidden email]>: >>>> >>>> >>>> >>>>>I just went through all VW monolithic VMs from 2.0 to 7.7.1 with >>>>>Dependency Walker: >>>>> >>>>>2.0 and 2.5 statically linked any functions they called from >>>>>msvcrt.dll >>>>> >>>>>3.0 dynamically linked msvcrt40.dll, but 3.0b already changed that >>>>>to just msvcrt.dll. >>>>> >>>>>5i.3 - 7.7.1 have all dynamically linked msvcrt.dll, which has been >>>>>an obligatory part of standard Windows installs for over a decade >>>>><http://en.wikipedia.org/wiki/Microsoft_Windows_library_files#Msvcrt >>>>>.dll >>>>> >>>>> >>>>>> (Windows 2000 on), in Windows\system32 (and before that part of a >>>>>> >>>>>> >>>>>normal Windows install since at least Windows 95 >>>>><http://support.microsoft.com/kb/895959> ). >>>>> >>>>> >>>>>There's a big difference >>>>><http://msdn.microsoft.com/en- >>>>> >>>>> >>us/library/abx4dbyh(VS.71).aspx#CodeSp >> >> >>>>>ippe >>>>>t0> between msvcrt.dll (a system file) and msvcr[71-100].dll. The >>>>>former is guaranteed to be found (although you have no control over >>>>>the exact version), the latter must be installed with your application. >>>>> >>>>> >>>>>In theory you shouldn't rely on the system msvcrt.dll, since it will >>>>>be a different version from what you used in your own testing, but >>>>>in practice for VW this seems to have worked well. I imagine VW's >>>>>reliance is pretty generic and stable, so it's been more likely that >>>>>things improved when MS shipped an update to msvcrt.dll, than that >>>>>things would break. XP SP2 was the exception, as the significant >>>>>changes it introduced caused problems in many applications. It looks >>>>>like Microsoft are moving away from allowing 3rd party apps to >>>>>dynamically link to the system msvcrt.dll, so Cincom should stop >>>>>too. There's a good discussion >>>>><http://stackoverflow.com/questions/1073509/should-i-redistribute-ms >>>>>vcrt >>>>>-dll-with-my-application> on the pros and cons on StackOverflow. >>>>> >>>>> >>>>>So, with the exception of 3.0 (which was corrected in 3.0b), no >>>>>previous VM has dynamically depended on a particular >>>>>msvcr[40-100].dll. Those particular DLLs aren't shipped with >>>>>Windows, and if you depend on them you MUST ship them. >>>>> >>>>> >>>>>Better though would be to statically link the CRT for the 64-bit VM, >>>>>using /MT. That would also seem to be good advice for the 32-bit VM, >>>>>to remove the dependency on the system msvcrt.dll. Statically >>>>>linking the 64-bit VM will also significantly reduce the total size >>>>>of the application, since I imagine VW only uses a tiny fraction of >>>>>the whole msvcrt100.dll. >>>>> >>>>> >>>>>Cheers, >>>>> >>>>>Steve >>>>> >>>>> >>>>> >>>>>From: [hidden email] [mailto:vw-dev- >>>>> >>>>> >>[hidden email]] >> >> >>>>>On Behalf Of Alan Knight >>>>>Sent: 11. helmikuuta 2011 1:34 >>>>>To: [hidden email] >>>>>Subject: Re: vw7.8 64-bit on windows error >>>>> >>>>> >>>>>I don't think we have statically linked the MSVCR libraries in >>>>>previous versions, at least not for a very long time. I also don't >>>>>think that those libraries are part of the Windows installs, but >>>>>they tended to be there if you'd installed anything at all. And >>>>>possibly if the operating system included programs that were built >>>>>with those compilers they would be for practical purposes included. >>>>>The difference in this case is, I suspect, that people have fewer >>>>>things installed that are 64-bit applications, and the compiler is newer. >>>>> >>>>>It is not needed on 32-bit installations, because we are for the >>>>>moment still using an older compiler version for the 32-bit >>>>>versions, partly because of that dependency. Building the 64-bit >>>>>versions required the use of the more recent compiler. 32-bit >>>>>versions appear to my untrained eye to require MSVCRT.DLL with no >>>>>version number embedded in the name. I don't believe it makes any >>>>> >>>>> >>difference between visual.exe and vwnt.exe. >> >> >>>>>It's possible that we really ought to be installing it, but it is >>>>>not something we've ever done in the past and it does not seem to >>>>>have previously been an issue. >>>>> >>>>> >>>>> >>>>>In earlier versions, the necessary parts of the MSVCR library have >>>>>been statically linked (IIRC), or then the relevant library has been >>>>>part of a normal Windows installation anyway (maybe in IE?). Even >>>>>the Cairo DLL was kindly made by Travis to be statically linked >>>>>rather than require >>>>>MSCVR90.dll: >>>>> >>>>>http://www.parcplace.net/list/vwnc-archive/0910/msg00085.html >>>>> >>>>>Information on static linking and msvcr100.dll is in the last >>>>>message >>>>>here: >>>>> >>>>> >>>>> >>>>> >>http://social.msdn.microsoft.com/Forums/en/vssetup/thread/6891665f-f >> >> >>>>>d83- >>>>>426a-9d73-69d6d7e171a3 >>>>> >>>>> >>>>>As Martin said, a vendor using a redistributable dynamically linked >>>>>library like this is expected to ship it as part of their installer >>>>>- as can be seen from e.g. InstallShield, which comes with a wide >>>>>range of redistributables that install builders can add to their >>>>>install. It's also what Microsoft says to do (IIUC): >>>>> >>>>>http://msdn.microsoft.com/en-us/library/ms235299.aspx >>>>> >>>>>"If you use a merge module that contains a Visual C++ DLL, you must >>>>>include it in the Windows Installer package (or similar installation >>>>>package) that you are using to deploy the application" >>>>> >>>>> >>>>>Of course, all this is just for what Cincom should do when providing >>>>>their product, if that product were just an application. Given the >>>>>product in this case is a development environment, Cincom should >>>>>also provide automation and/or instructions for developers to create >>>>>and deploy their own products - including any necessary >>>>> >>>>> >>redistributables. >> >> >>>>>Otherwise end users are going to be reporting that the application >>>>>doesn't work, and developers aren't going to understand why (and >>>>>presumably Cincom isn't going to get any royalties in that case!). >>>>> >>>>> >>>>>Is msvcr100.dll also needed on 32-bit VW 7.8 installations on Windows? >>>>>Does it make a difference if we use the monolithic visual.exe VM or >>>>>the split .exe+.dll VM? >>>>> >>>>> >>>>>Cheers, >>>>> >>>>>Steve >>>>> >>>>> >>>>> >>>>>________________________________ >>>>> >>>>>From: [hidden email] on behalf of Alan Knight >>>>>Sent: Thu 10/02/2011 19:55 >>>>>To: Martin McClure >>>>>Cc: [hidden email] >>>>>Subject: Re: vw7.8 64-bit on windows error >>>>> >>>>> >>>>>That isn't something we've done in the past. I think that typically >>>>>those libraries end up installed quite widely as soon as you've >>>>>installed anything. And it would be a bit tricky, in that it >>>>>wouldn't be integrated with our installation mechanisms. I think >>>>>about the best we could do at this point would be to include a copy >>>>>on the CD or download and people would have to install it >>>>>themselves. We can also look into trying to do something in the next >>>>>release when we expect to have Win64 as fully supported, but it's quite >>>>> >>>>> >>late to try much for this one. >> >> >>>>>On 2011-02-10 12:09 AM, Martin McClure wrote: >>>>> >>>>> >>>>>>On 02/09/11 11:11, Alan Knight wrote: >>>>>> >>>>>> >>>>>>>you need to install the appropriate MS runtime for the most recent >>>>>>>compiler. >>>>>>> >>>>>>> >>>>>>I'd gotten the impression that Microsoft's intent is that when an >>>>>>application requires a particular version of the MSVCR library, the >>>>>>application vendor should ship that MSVCR library along with the >>>>>>application. >>>>>> >>>>>>Would it be possible to include that with the Windows install? >>>>>> >>>>>>Regards, >>>>>> >>>>>>-Martin >>>>>> >>>>>> >>>>>-- >>>>>Alan Knight [|], Engineering Manager, Cincom Smalltalk >>>>>[hidden email] [hidden email] http://www.cincomsmalltalk.com >>>>><http://www.cincomsmalltalk.com/> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>_______________________________________________ >>vwnc mailing list >>[hidden email] >>http://lists.cs.uiuc.edu/mailman/listinfo/vwnc >> >> >> > > >_______________________________________________ >vwnc mailing list >[hidden email] >http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > > > > _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: [now vw7.9] msvcr100.dll Re: vw7.8 64-bit on windows error
|
|
Niall,
Thanks for the clarification. So if the question is "is it okay that msvcr100.dll needs to distributed with VisualWorks?" For me the answer would have to be no. Telling my customers that they now need to include this DLL represents a broken promise. It is not possible to statically link the needed functions because these functions may become broken? Or is it possible but inconvenient? But the msvcr100.dll may also become broken? I'm not sure why Microsoft doesn't simply provide this DLL and keep it up to date using Windows Update. So I'll be stuck with VW7.8 until it no longer works. I hope that will be a very long time coming. -Carl Gundel Liberty BASIC for Windows - http://www.libertybasic.com Run BASIC, easy web programming - http://www.runbasic.com On Jul 15, 2012, at 5:21 PM, Niall Ross <[hidden email]> wrote: > Dear Carl, Christian, David et al, > the msvcr100.dll does not have to be installed in a system location. > > For example, the 7.9 VW installer puts it in the system location if it can write to that location. If it cannot, it puts dll in VW's bin/win (and 64bit in bin/win64). Similarly, any app installer can put the dll in the same location as their VM or single file .exe. > > A local msvcr100.dll acts > > - as the one used by our VM if no system one is installed on that platform > > - as a softlink to the system one if present: our VM always uses the system one if present > > As of VS2010, Microsoft no longer include the dll in its base platforms. This is the change we are responding to - the corresponding prior versions have always been there by default so we never had to install them. (Actually, the dll is there,but hidden, only for MS internal stuff and not promised to remain compatible.) Thus the VS2010 and later dll has to be either > - installed in system > or > - installed locally > or > - statically linked > > So the corresponding single-file .exe options are: > > a) "the full install dance" - almost certainly what you don't want to do if you're using the single file option > > b) Have your zip expand to YourApp.exe and msvcr100.dll, not just YourApp.exe. As noted, if your customer later installs or upgrade a system msvcr100.dll, it will all still work. (If you want, you can have your installation notes tell the user: "If you can put our msvcr100.dll in the bin and the .exe still works, leave it in the bin - you don't need it." This merely saves them ~750K of space; no other point.) > > c) Statically-link the dll to the VM: the difference from (b) is that if the user upgrades their platform, you will not upgrade with it, so we're not starting by encouraging this option. We're hoping our customers will say that (b) is OK. > > (The relevant Microsoft team promise future backward compatibility of the dll in all cases but discovery of major security hole.) > > HTH > Niall Ross > > >> Yes, this is going to be a show-stopper for using VW 7.9 for me as well :-( >> >> But since linking the DLLs statically to the VMs for Windows needs to be done only once, maybe somebody did this and could share the VM with the community? >> >> I wonder why Cincom is not able to provide such a VM... Is it so hard to do or are there legal issues involved? >> >> I really hope that there will be a practical solution to this problem without having to dive into C land to figure out how to do that myself... >> >> Christian >> >> >>> -----Ursprüngliche Nachricht----- >>> Von: [hidden email] [mailto:[hidden email]] Im >>> Auftrag von Carl Gundel >>> Gesendet: Sonntag, 15. Juli 2012 06:31 >>> An: VWNC List >>> Betreff: [vwnc] [now vw7.9] msvcr100.dll Re: vw7.8 64-bit on windows error >>> >>>> From the 7.9 release notes: >>> >>> "Windows OE DLL Requirement >>> Due to a compiler upgrade, the Windows VMs require that msvcr100.dll be >>> installed in its proper location (System32 or SysWOW64).If this DLL is not >>> already installed, the installer installs and runs a program >>> (VisualWorks32bitDLLPrereqs, and VisualWorks64bitDLLPrereqs on 64-bit >>> systems) that installs the DLL(s) and registers VisualWorks' interest in them. >>> After installation, an information screen tells you this has been done. If you >>> uninstall this program, VisualWorks is deregistered for it, and the DLL is >>> removed if no other program has an interest. >>> When deploying an application with the VM, you are responsible for ensuring >>> that this file is present on the target system." >>> >>> So, this is now required for 32-bit VisualWorks on Windows also? >>> >>> This is going to be very, very inconvenient for me. The single file VM and the >>> ability to embed the image in the VM are one of the reasons I chose >>> VisualWorks. Up to this point I have not needed any extra libraries and this is >>> very important to me and to my customers. The msvcr100.dll throws a real >>> monkey wrench into things for me. I hope that Cincom will decide to >>> statically link whatever functions it needs from this DLL going forward. I may >>> be forced to stick with 7.8 otherwise. >>> >>> -Carl Gundel >>> http://www.libertybasic.com >>> http://www.runbasic.com >>> >>> On Sun, Feb 20, 2011 at 10:29 AM, Alan Knight <[hidden email]> wrote: >>> >>>> Yes, this is expected. We'll need to do something about that, but for >>>> 7.8, where win64 is in preview, I think it's likely to remain and >>>> we'll sort out the various possibilities with a bit more time to consider. >>>> >>>> >>>> On 11-02-20 6:36 AM, Steffen Märcker wrote: >>>> >>>>> I've just attempted to start the win64 vm on Windows 7 Prof. 64 Bit >>>>> and got the message to install msvcr100.dll too. Do I understand this >>>>> thread right that this is actually expected? >>>>> >>>>> Regards, Steffen >>>>> >>>>> >>>>> Am 11.02.2011, 11:17 Uhr, schrieb Steven Kelly <[hidden email]>: >>>>> >>>>> >>>>>> I just went through all VW monolithic VMs from 2.0 to 7.7.1 with >>>>>> Dependency Walker: >>>>>> >>>>>> 2.0 and 2.5 statically linked any functions they called from >>>>>> msvcrt.dll >>>>>> >>>>>> 3.0 dynamically linked msvcrt40.dll, but 3.0b already changed that >>>>>> to just msvcrt.dll. >>>>>> >>>>>> 5i.3 - 7.7.1 have all dynamically linked msvcrt.dll, which has been >>>>>> an obligatory part of standard Windows installs for over a decade >>>>>> <http://en.wikipedia.org/wiki/Microsoft_Windows_library_files#Msvcrt >>>>>> .dll >>>>>> >>>>>>> (Windows 2000 on), in Windows\system32 (and before that part of a >>>>>>> >>>>>> normal Windows install since at least Windows 95 >>>>>> <http://support.microsoft.com/kb/895959> ). >>>>>> >>>>>> >>>>>> There's a big difference >>>>>> <http://msdn.microsoft.com/en- >>>>>> >>> us/library/abx4dbyh(VS.71).aspx#CodeSp >>> >>>>>> ippe >>>>>> t0> between msvcrt.dll (a system file) and msvcr[71-100].dll. The >>>>>> former is guaranteed to be found (although you have no control over >>>>>> the exact version), the latter must be installed with your application. >>>>>> >>>>>> >>>>>> In theory you shouldn't rely on the system msvcrt.dll, since it will >>>>>> be a different version from what you used in your own testing, but >>>>>> in practice for VW this seems to have worked well. I imagine VW's >>>>>> reliance is pretty generic and stable, so it's been more likely that >>>>>> things improved when MS shipped an update to msvcrt.dll, than that >>>>>> things would break. XP SP2 was the exception, as the significant >>>>>> changes it introduced caused problems in many applications. It looks >>>>>> like Microsoft are moving away from allowing 3rd party apps to >>>>>> dynamically link to the system msvcrt.dll, so Cincom should stop >>>>>> too. There's a good discussion >>>>>> <http://stackoverflow.com/questions/1073509/should-i-redistribute-ms >>>>>> vcrt >>>>>> -dll-with-my-application> on the pros and cons on StackOverflow. >>>>>> >>>>>> >>>>>> So, with the exception of 3.0 (which was corrected in 3.0b), no >>>>>> previous VM has dynamically depended on a particular >>>>>> msvcr[40-100].dll. Those particular DLLs aren't shipped with >>>>>> Windows, and if you depend on them you MUST ship them. >>>>>> >>>>>> >>>>>> Better though would be to statically link the CRT for the 64-bit VM, >>>>>> using /MT. That would also seem to be good advice for the 32-bit VM, >>>>>> to remove the dependency on the system msvcrt.dll. Statically >>>>>> linking the 64-bit VM will also significantly reduce the total size >>>>>> of the application, since I imagine VW only uses a tiny fraction of >>>>>> the whole msvcrt100.dll. >>>>>> >>>>>> >>>>>> Cheers, >>>>>> >>>>>> Steve >>>>>> >>>>>> >>>>>> >>>>>> From: [hidden email] [mailto:vw-dev- >>>>>> >>> [hidden email]] >>> >>>>>> On Behalf Of Alan Knight >>>>>> Sent: 11. helmikuuta 2011 1:34 >>>>>> To: [hidden email] >>>>>> Subject: Re: vw7.8 64-bit on windows error >>>>>> >>>>>> >>>>>> I don't think we have statically linked the MSVCR libraries in >>>>>> previous versions, at least not for a very long time. I also don't >>>>>> think that those libraries are part of the Windows installs, but >>>>>> they tended to be there if you'd installed anything at all. And >>>>>> possibly if the operating system included programs that were built >>>>>> with those compilers they would be for practical purposes included. >>>>>> The difference in this case is, I suspect, that people have fewer >>>>>> things installed that are 64-bit applications, and the compiler is newer. >>>>>> >>>>>> It is not needed on 32-bit installations, because we are for the >>>>>> moment still using an older compiler version for the 32-bit >>>>>> versions, partly because of that dependency. Building the 64-bit >>>>>> versions required the use of the more recent compiler. 32-bit >>>>>> versions appear to my untrained eye to require MSVCRT.DLL with no >>>>>> version number embedded in the name. I don't believe it makes any >>>>>> >>> difference between visual.exe and vwnt.exe. >>> >>>>>> It's possible that we really ought to be installing it, but it is >>>>>> not something we've ever done in the past and it does not seem to >>>>>> have previously been an issue. >>>>>> >>>>>> >>>>>> >>>>>> In earlier versions, the necessary parts of the MSVCR library have >>>>>> been statically linked (IIRC), or then the relevant library has been >>>>>> part of a normal Windows installation anyway (maybe in IE?). Even >>>>>> the Cairo DLL was kindly made by Travis to be statically linked >>>>>> rather than require >>>>>> MSCVR90.dll: >>>>>> >>>>>> http://www.parcplace.net/list/vwnc-archive/0910/msg00085.html >>>>>> >>>>>> Information on static linking and msvcr100.dll is in the last >>>>>> message >>>>>> here: >>>>>> >>>>>> >>>>>> >>> http://social.msdn.microsoft.com/Forums/en/vssetup/thread/6891665f-f >>> >>>>>> d83- >>>>>> 426a-9d73-69d6d7e171a3 >>>>>> >>>>>> >>>>>> As Martin said, a vendor using a redistributable dynamically linked >>>>>> library like this is expected to ship it as part of their installer >>>>>> - as can be seen from e.g. InstallShield, which comes with a wide >>>>>> range of redistributables that install builders can add to their >>>>>> install. It's also what Microsoft says to do (IIUC): >>>>>> >>>>>> http://msdn.microsoft.com/en-us/library/ms235299.aspx >>>>>> >>>>>> "If you use a merge module that contains a Visual C++ DLL, you must >>>>>> include it in the Windows Installer package (or similar installation >>>>>> package) that you are using to deploy the application" >>>>>> >>>>>> >>>>>> Of course, all this is just for what Cincom should do when providing >>>>>> their product, if that product were just an application. Given the >>>>>> product in this case is a development environment, Cincom should >>>>>> also provide automation and/or instructions for developers to create >>>>>> and deploy their own products - including any necessary >>>>>> >>> redistributables. >>> >>>>>> Otherwise end users are going to be reporting that the application >>>>>> doesn't work, and developers aren't going to understand why (and >>>>>> presumably Cincom isn't going to get any royalties in that case!). >>>>>> >>>>>> >>>>>> Is msvcr100.dll also needed on 32-bit VW 7.8 installations on Windows? >>>>>> Does it make a difference if we use the monolithic visual.exe VM or >>>>>> the split .exe+.dll VM? >>>>>> >>>>>> >>>>>> Cheers, >>>>>> >>>>>> Steve >>>>>> >>>>>> >>>>>> >>>>>> ________________________________ >>>>>> >>>>>> From: [hidden email] on behalf of Alan Knight >>>>>> Sent: Thu 10/02/2011 19:55 >>>>>> To: Martin McClure >>>>>> Cc: [hidden email] >>>>>> Subject: Re: vw7.8 64-bit on windows error >>>>>> >>>>>> >>>>>> That isn't something we've done in the past. I think that typically >>>>>> those libraries end up installed quite widely as soon as you've >>>>>> installed anything. And it would be a bit tricky, in that it >>>>>> wouldn't be integrated with our installation mechanisms. I think >>>>>> about the best we could do at this point would be to include a copy >>>>>> on the CD or download and people would have to install it >>>>>> themselves. We can also look into trying to do something in the next >>>>>> release when we expect to have Win64 as fully supported, but it's quite >>>>>> >>> late to try much for this one. >>> >>>>>> On 2011-02-10 12:09 AM, Martin McClure wrote: >>>>>> >>>>>>> On 02/09/11 11:11, Alan Knight wrote: >>>>>>> >>>>>>>> you need to install the appropriate MS runtime for the most recent >>>>>>>> compiler. >>>>>>>> >>>>>>> I'd gotten the impression that Microsoft's intent is that when an >>>>>>> application requires a particular version of the MSVCR library, the >>>>>>> application vendor should ship that MSVCR library along with the >>>>>>> application. >>>>>>> >>>>>>> Would it be possible to include that with the Windows install? >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> -Martin >>>>>>> >>>>>> -- >>>>>> Alan Knight [|], Engineering Manager, Cincom Smalltalk >>>>>> [hidden email] [hidden email] http://www.cincomsmalltalk.com >>>>>> <http://www.cincomsmalltalk.com/> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>> _______________________________________________ >>> vwnc mailing list >>> [hidden email] >>> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc >>> >>> >> >> >> _______________________________________________ >> vwnc mailing list >> [hidden email] >> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc >> >> >> > > _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: [now vw7.9] msvcr100.dll Re: vw7.8 64-bit onwindows error
|
|
Don't worry, you're not the only one stuck on 7.8(.1); for us the issues with TLS/SSL compatibility make the move impossible at this point. Let's see what 7.10 brings us.
-Boris On 2012-07-15, at 20:32, "Carl Gundel" <[hidden email]> wrote: > Niall, > > Thanks for the clarification. So if the question is "is it okay that msvcr100.dll needs to distributed with VisualWorks?" > > For me the answer would have to be no. Telling my customers that they now need to include this DLL represents a broken promise. > > It is not possible to statically link the needed functions because these functions may become broken? Or is it possible but inconvenient? But the msvcr100.dll may also become broken? > > I'm not sure why Microsoft doesn't simply provide this DLL and keep it up to date using Windows Update. > > So I'll be stuck with VW7.8 until it no longer works. I hope that will be a very long time coming. > > -Carl Gundel > Liberty BASIC for Windows - http://www.libertybasic.com > Run BASIC, easy web programming - http://www.runbasic.com > > On Jul 15, 2012, at 5:21 PM, Niall Ross <[hidden email]> wrote: > >> Dear Carl, Christian, David et al, >> the msvcr100.dll does not have to be installed in a system location. >> >> For example, the 7.9 VW installer puts it in the system location if it can write to that location. If it cannot, it puts dll in VW's bin/win (and 64bit in bin/win64). Similarly, any app installer can put the dll in the same location as their VM or single file .exe. >> >> A local msvcr100.dll acts >> >> - as the one used by our VM if no system one is installed on that platform >> >> - as a softlink to the system one if present: our VM always uses the system one if present >> >> As of VS2010, Microsoft no longer include the dll in its base platforms. This is the change we are responding to - the corresponding prior versions have always been there by default so we never had to install them. (Actually, the dll is there,but hidden, only for MS internal stuff and not promised to remain compatible.) Thus the VS2010 and later dll has to be either >> - installed in system >> or >> - installed locally >> or >> - statically linked >> >> So the corresponding single-file .exe options are: >> >> a) "the full install dance" - almost certainly what you don't want to do if you're using the single file option >> >> b) Have your zip expand to YourApp.exe and msvcr100.dll, not just YourApp.exe. As noted, if your customer later installs or upgrade a system msvcr100.dll, it will all still work. (If you want, you can have your installation notes tell the user: "If you can put our msvcr100.dll in the bin and the .exe still works, leave it in the bin - you don't need it." This merely saves them ~750K of space; no other point.) >> >> c) Statically-link the dll to the VM: the difference from (b) is that if the user upgrades their platform, you will not upgrade with it, so we're not starting by encouraging this option. We're hoping our customers will say that (b) is OK. >> >> (The relevant Microsoft team promise future backward compatibility of the dll in all cases but discovery of major security hole.) >> >> HTH >> Niall Ross >> >> >>> Yes, this is going to be a show-stopper for using VW 7.9 for me as well :-( >>> >>> But since linking the DLLs statically to the VMs for Windows needs to be done only once, maybe somebody did this and could share the VM with the community? >>> >>> I wonder why Cincom is not able to provide such a VM... Is it so hard to do or are there legal issues involved? >>> >>> I really hope that there will be a practical solution to this problem without having to dive into C land to figure out how to do that myself... >>> >>> Christian >>> >>> >>>> -----Ursprüngliche Nachricht----- >>>> Von: [hidden email] [mailto:[hidden email]] Im >>>> Auftrag von Carl Gundel >>>> Gesendet: Sonntag, 15. Juli 2012 06:31 >>>> An: VWNC List >>>> Betreff: [vwnc] [now vw7.9] msvcr100.dll Re: vw7.8 64-bit on windows error >>>> >>>>> From the 7.9 release notes: >>>> >>>> "Windows OE DLL Requirement >>>> Due to a compiler upgrade, the Windows VMs require that msvcr100.dll be >>>> installed in its proper location (System32 or SysWOW64).If this DLL is not >>>> already installed, the installer installs and runs a program >>>> (VisualWorks32bitDLLPrereqs, and VisualWorks64bitDLLPrereqs on 64-bit >>>> systems) that installs the DLL(s) and registers VisualWorks' interest in them. >>>> After installation, an information screen tells you this has been done. If you >>>> uninstall this program, VisualWorks is deregistered for it, and the DLL is >>>> removed if no other program has an interest. >>>> When deploying an application with the VM, you are responsible for ensuring >>>> that this file is present on the target system." >>>> >>>> So, this is now required for 32-bit VisualWorks on Windows also? >>>> >>>> This is going to be very, very inconvenient for me. The single file VM and the >>>> ability to embed the image in the VM are one of the reasons I chose >>>> VisualWorks. Up to this point I have not needed any extra libraries and this is >>>> very important to me and to my customers. The msvcr100.dll throws a real >>>> monkey wrench into things for me. I hope that Cincom will decide to >>>> statically link whatever functions it needs from this DLL going forward. I may >>>> be forced to stick with 7.8 otherwise. >>>> >>>> -Carl Gundel >>>> http://www.libertybasic.com >>>> http://www.runbasic.com >>>> >>>> On Sun, Feb 20, 2011 at 10:29 AM, Alan Knight <[hidden email]> wrote: >>>> >>>>> Yes, this is expected. We'll need to do something about that, but for >>>>> 7.8, where win64 is in preview, I think it's likely to remain and >>>>> we'll sort out the various possibilities with a bit more time to consider. >>>>> >>>>> >>>>> On 11-02-20 6:36 AM, Steffen Märcker wrote: >>>>> >>>>>> I've just attempted to start the win64 vm on Windows 7 Prof. 64 Bit >>>>>> and got the message to install msvcr100.dll too. Do I understand this >>>>>> thread right that this is actually expected? >>>>>> >>>>>> Regards, Steffen >>>>>> >>>>>> >>>>>> Am 11.02.2011, 11:17 Uhr, schrieb Steven Kelly <[hidden email]>: >>>>>> >>>>>> >>>>>>> I just went through all VW monolithic VMs from 2.0 to 7.7.1 with >>>>>>> Dependency Walker: >>>>>>> >>>>>>> 2.0 and 2.5 statically linked any functions they called from >>>>>>> msvcrt.dll >>>>>>> >>>>>>> 3.0 dynamically linked msvcrt40.dll, but 3.0b already changed that >>>>>>> to just msvcrt.dll. >>>>>>> >>>>>>> 5i.3 - 7.7.1 have all dynamically linked msvcrt.dll, which has been >>>>>>> an obligatory part of standard Windows installs for over a decade >>>>>>> <http://en.wikipedia.org/wiki/Microsoft_Windows_library_files#Msvcrt >>>>>>> .dll >>>>>>> >>>>>>>> (Windows 2000 on), in Windows\system32 (and before that part of a >>>>>>>> >>>>>>> normal Windows install since at least Windows 95 >>>>>>> <http://support.microsoft.com/kb/895959> ). >>>>>>> >>>>>>> >>>>>>> There's a big difference >>>>>>> <http://msdn.microsoft.com/en- >>>>>>> >>>> us/library/abx4dbyh(VS.71).aspx#CodeSp >>>> >>>>>>> ippe >>>>>>> t0> between msvcrt.dll (a system file) and msvcr[71-100].dll. The >>>>>>> former is guaranteed to be found (although you have no control over >>>>>>> the exact version), the latter must be installed with your application. >>>>>>> >>>>>>> >>>>>>> In theory you shouldn't rely on the system msvcrt.dll, since it will >>>>>>> be a different version from what you used in your own testing, but >>>>>>> in practice for VW this seems to have worked well. I imagine VW's >>>>>>> reliance is pretty generic and stable, so it's been more likely that >>>>>>> things improved when MS shipped an update to msvcrt.dll, than that >>>>>>> things would break. XP SP2 was the exception, as the significant >>>>>>> changes it introduced caused problems in many applications. It looks >>>>>>> like Microsoft are moving away from allowing 3rd party apps to >>>>>>> dynamically link to the system msvcrt.dll, so Cincom should stop >>>>>>> too. There's a good discussion >>>>>>> <http://stackoverflow.com/questions/1073509/should-i-redistribute-ms >>>>>>> vcrt >>>>>>> -dll-with-my-application> on the pros and cons on StackOverflow. >>>>>>> >>>>>>> >>>>>>> So, with the exception of 3.0 (which was corrected in 3.0b), no >>>>>>> previous VM has dynamically depended on a particular >>>>>>> msvcr[40-100].dll. Those particular DLLs aren't shipped with >>>>>>> Windows, and if you depend on them you MUST ship them. >>>>>>> >>>>>>> >>>>>>> Better though would be to statically link the CRT for the 64-bit VM, >>>>>>> using /MT. That would also seem to be good advice for the 32-bit VM, >>>>>>> to remove the dependency on the system msvcrt.dll. Statically >>>>>>> linking the 64-bit VM will also significantly reduce the total size >>>>>>> of the application, since I imagine VW only uses a tiny fraction of >>>>>>> the whole msvcrt100.dll. >>>>>>> >>>>>>> >>>>>>> Cheers, >>>>>>> >>>>>>> Steve >>>>>>> >>>>>>> >>>>>>> >>>>>>> From: [hidden email] [mailto:vw-dev- >>>>>>> >>>> [hidden email]] >>>> >>>>>>> On Behalf Of Alan Knight >>>>>>> Sent: 11. helmikuuta 2011 1:34 >>>>>>> To: [hidden email] >>>>>>> Subject: Re: vw7.8 64-bit on windows error >>>>>>> >>>>>>> >>>>>>> I don't think we have statically linked the MSVCR libraries in >>>>>>> previous versions, at least not for a very long time. I also don't >>>>>>> think that those libraries are part of the Windows installs, but >>>>>>> they tended to be there if you'd installed anything at all. And >>>>>>> possibly if the operating system included programs that were built >>>>>>> with those compilers they would be for practical purposes included. >>>>>>> The difference in this case is, I suspect, that people have fewer >>>>>>> things installed that are 64-bit applications, and the compiler is newer. >>>>>>> >>>>>>> It is not needed on 32-bit installations, because we are for the >>>>>>> moment still using an older compiler version for the 32-bit >>>>>>> versions, partly because of that dependency. Building the 64-bit >>>>>>> versions required the use of the more recent compiler. 32-bit >>>>>>> versions appear to my untrained eye to require MSVCRT.DLL with no >>>>>>> version number embedded in the name. I don't believe it makes any >>>>>>> >>>> difference between visual.exe and vwnt.exe. >>>> >>>>>>> It's possible that we really ought to be installing it, but it is >>>>>>> not something we've ever done in the past and it does not seem to >>>>>>> have previously been an issue. >>>>>>> >>>>>>> >>>>>>> >>>>>>> In earlier versions, the necessary parts of the MSVCR library have >>>>>>> been statically linked (IIRC), or then the relevant library has been >>>>>>> part of a normal Windows installation anyway (maybe in IE?). Even >>>>>>> the Cairo DLL was kindly made by Travis to be statically linked >>>>>>> rather than require >>>>>>> MSCVR90.dll: >>>>>>> >>>>>>> http://www.parcplace.net/list/vwnc-archive/0910/msg00085.html >>>>>>> >>>>>>> Information on static linking and msvcr100.dll is in the last >>>>>>> message >>>>>>> here: >>>>>>> >>>>>>> >>>>>>> >>>> http://social.msdn.microsoft.com/Forums/en/vssetup/thread/6891665f-f >>>> >>>>>>> d83- >>>>>>> 426a-9d73-69d6d7e171a3 >>>>>>> >>>>>>> >>>>>>> As Martin said, a vendor using a redistributable dynamically linked >>>>>>> library like this is expected to ship it as part of their installer >>>>>>> - as can be seen from e.g. InstallShield, which comes with a wide >>>>>>> range of redistributables that install builders can add to their >>>>>>> install. It's also what Microsoft says to do (IIUC): >>>>>>> >>>>>>> http://msdn.microsoft.com/en-us/library/ms235299.aspx >>>>>>> >>>>>>> "If you use a merge module that contains a Visual C++ DLL, you must >>>>>>> include it in the Windows Installer package (or similar installation >>>>>>> package) that you are using to deploy the application" >>>>>>> >>>>>>> >>>>>>> Of course, all this is just for what Cincom should do when providing >>>>>>> their product, if that product were just an application. Given the >>>>>>> product in this case is a development environment, Cincom should >>>>>>> also provide automation and/or instructions for developers to create >>>>>>> and deploy their own products - including any necessary >>>>>>> >>>> redistributables. >>>> >>>>>>> Otherwise end users are going to be reporting that the application >>>>>>> doesn't work, and developers aren't going to understand why (and >>>>>>> presumably Cincom isn't going to get any royalties in that case!). >>>>>>> >>>>>>> >>>>>>> Is msvcr100.dll also needed on 32-bit VW 7.8 installations on Windows? >>>>>>> Does it make a difference if we use the monolithic visual.exe VM or >>>>>>> the split .exe+.dll VM? >>>>>>> >>>>>>> >>>>>>> Cheers, >>>>>>> >>>>>>> Steve >>>>>>> >>>>>>> >>>>>>> >>>>>>> ________________________________ >>>>>>> >>>>>>> From: [hidden email] on behalf of Alan Knight >>>>>>> Sent: Thu 10/02/2011 19:55 >>>>>>> To: Martin McClure >>>>>>> Cc: [hidden email] >>>>>>> Subject: Re: vw7.8 64-bit on windows error >>>>>>> >>>>>>> >>>>>>> That isn't something we've done in the past. I think that typically >>>>>>> those libraries end up installed quite widely as soon as you've >>>>>>> installed anything. And it would be a bit tricky, in that it >>>>>>> wouldn't be integrated with our installation mechanisms. I think >>>>>>> about the best we could do at this point would be to include a copy >>>>>>> on the CD or download and people would have to install it >>>>>>> themselves. We can also look into trying to do something in the next >>>>>>> release when we expect to have Win64 as fully supported, but it's quite >>>>>>> >>>> late to try much for this one. >>>> >>>>>>> On 2011-02-10 12:09 AM, Martin McClure wrote: >>>>>>> >>>>>>>> On 02/09/11 11:11, Alan Knight wrote: >>>>>>>> >>>>>>>>> you need to install the appropriate MS runtime for the most recent >>>>>>>>> compiler. >>>>>>>>> >>>>>>>> I'd gotten the impression that Microsoft's intent is that when an >>>>>>>> application requires a particular version of the MSVCR library, the >>>>>>>> application vendor should ship that MSVCR library along with the >>>>>>>> application. >>>>>>>> >>>>>>>> Would it be possible to include that with the Windows install? >>>>>>>> >>>>>>>> Regards, >>>>>>>> >>>>>>>> -Martin >>>>>>>> >>>>>>> -- >>>>>>> Alan Knight [|], Engineering Manager, Cincom Smalltalk >>>>>>> [hidden email] [hidden email] http://www.cincomsmalltalk.com >>>>>>> <http://www.cincomsmalltalk.com/> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>> _______________________________________________ >>>> vwnc mailing list >>>> [hidden email] >>>> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc >>>> >>>> >>> >>> >>> _______________________________________________ >>> vwnc mailing list >>> [hidden email] >>> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc >>> >>> >>> >> >> > > _______________________________________________ > vwnc mailing list > [hidden email] > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: [now vw7.9] msvcr100.dll Re: vw7.8 64-bit onwindows error
|
|
Fair enough. Let's see about 7.10.
-Carl Gundel Liberty BASIC for Windows - http://www.libertybasic.com Run BASIC, easy web programming - http://www.runbasic.com On Jul 15, 2012, at 9:50 PM, "Boris Popov, DeepCove Labs" <[hidden email]> wrote: > Don't worry, you're not the only one stuck on 7.8(.1); for us the issues with TLS/SSL compatibility make the move impossible at this point. Let's see what 7.10 brings us. > > -Boris > > On 2012-07-15, at 20:32, "Carl Gundel" <[hidden email]> wrote: > >> Niall, >> >> Thanks for the clarification. So if the question is "is it okay that msvcr100.dll needs to distributed with VisualWorks?" >> >> For me the answer would have to be no. Telling my customers that they now need to include this DLL represents a broken promise. >> >> It is not possible to statically link the needed functions because these functions may become broken? Or is it possible but inconvenient? But the msvcr100.dll may also become broken? >> >> I'm not sure why Microsoft doesn't simply provide this DLL and keep it up to date using Windows Update. >> >> So I'll be stuck with VW7.8 until it no longer works. I hope that will be a very long time coming. >> >> -Carl Gundel >> Liberty BASIC for Windows - http://www.libertybasic.com >> Run BASIC, easy web programming - http://www.runbasic.com >> >> On Jul 15, 2012, at 5:21 PM, Niall Ross <[hidden email]> wrote: >> >>> Dear Carl, Christian, David et al, >>> the msvcr100.dll does not have to be installed in a system location. >>> >>> For example, the 7.9 VW installer puts it in the system location if it can write to that location. If it cannot, it puts dll in VW's bin/win (and 64bit in bin/win64). Similarly, any app installer can put the dll in the same location as their VM or single file .exe. >>> >>> A local msvcr100.dll acts >>> >>> - as the one used by our VM if no system one is installed on that platform >>> >>> - as a softlink to the system one if present: our VM always uses the system one if present >>> >>> As of VS2010, Microsoft no longer include the dll in its base platforms. This is the change we are responding to - the corresponding prior versions have always been there by default so we never had to install them. (Actually, the dll is there,but hidden, only for MS internal stuff and not promised to remain compatible.) Thus the VS2010 and later dll has to be either >>> - installed in system >>> or >>> - installed locally >>> or >>> - statically linked >>> >>> So the corresponding single-file .exe options are: >>> >>> a) "the full install dance" - almost certainly what you don't want to do if you're using the single file option >>> >>> b) Have your zip expand to YourApp.exe and msvcr100.dll, not just YourApp.exe. As noted, if your customer later installs or upgrade a system msvcr100.dll, it will all still work. (If you want, you can have your installation notes tell the user: "If you can put our msvcr100.dll in the bin and the .exe still works, leave it in the bin - you don't need it." This merely saves them ~750K of space; no other point.) >>> >>> c) Statically-link the dll to the VM: the difference from (b) is that if the user upgrades their platform, you will not upgrade with it, so we're not starting by encouraging this option. We're hoping our customers will say that (b) is OK. >>> >>> (The relevant Microsoft team promise future backward compatibility of the dll in all cases but discovery of major security hole.) >>> >>> HTH >>> Niall Ross >>> >>> >>>> Yes, this is going to be a show-stopper for using VW 7.9 for me as well :-( >>>> >>>> But since linking the DLLs statically to the VMs for Windows needs to be done only once, maybe somebody did this and could share the VM with the community? >>>> >>>> I wonder why Cincom is not able to provide such a VM... Is it so hard to do or are there legal issues involved? >>>> >>>> I really hope that there will be a practical solution to this problem without having to dive into C land to figure out how to do that myself... >>>> >>>> Christian >>>> >>>> >>>>> -----Ursprüngliche Nachricht----- >>>>> Von: [hidden email] [mailto:[hidden email]] Im >>>>> Auftrag von Carl Gundel >>>>> Gesendet: Sonntag, 15. Juli 2012 06:31 >>>>> An: VWNC List >>>>> Betreff: [vwnc] [now vw7.9] msvcr100.dll Re: vw7.8 64-bit on windows error >>>>> >>>>>> From the 7.9 release notes: >>>>> >>>>> "Windows OE DLL Requirement >>>>> Due to a compiler upgrade, the Windows VMs require that msvcr100.dll be >>>>> installed in its proper location (System32 or SysWOW64).If this DLL is not >>>>> already installed, the installer installs and runs a program >>>>> (VisualWorks32bitDLLPrereqs, and VisualWorks64bitDLLPrereqs on 64-bit >>>>> systems) that installs the DLL(s) and registers VisualWorks' interest in them. >>>>> After installation, an information screen tells you this has been done. If you >>>>> uninstall this program, VisualWorks is deregistered for it, and the DLL is >>>>> removed if no other program has an interest. >>>>> When deploying an application with the VM, you are responsible for ensuring >>>>> that this file is present on the target system." >>>>> >>>>> So, this is now required for 32-bit VisualWorks on Windows also? >>>>> >>>>> This is going to be very, very inconvenient for me. The single file VM and the >>>>> ability to embed the image in the VM are one of the reasons I chose >>>>> VisualWorks. Up to this point I have not needed any extra libraries and this is >>>>> very important to me and to my customers. The msvcr100.dll throws a real >>>>> monkey wrench into things for me. I hope that Cincom will decide to >>>>> statically link whatever functions it needs from this DLL going forward. I may >>>>> be forced to stick with 7.8 otherwise. >>>>> >>>>> -Carl Gundel >>>>> http://www.libertybasic.com >>>>> http://www.runbasic.com >>>>> >>>>> On Sun, Feb 20, 2011 at 10:29 AM, Alan Knight <[hidden email]> wrote: >>>>> >>>>>> Yes, this is expected. We'll need to do something about that, but for >>>>>> 7.8, where win64 is in preview, I think it's likely to remain and >>>>>> we'll sort out the various possibilities with a bit more time to consider. >>>>>> >>>>>> >>>>>> On 11-02-20 6:36 AM, Steffen Märcker wrote: >>>>>> >>>>>>> I've just attempted to start the win64 vm on Windows 7 Prof. 64 Bit >>>>>>> and got the message to install msvcr100.dll too. Do I understand this >>>>>>> thread right that this is actually expected? >>>>>>> >>>>>>> Regards, Steffen >>>>>>> >>>>>>> >>>>>>> Am 11.02.2011, 11:17 Uhr, schrieb Steven Kelly <[hidden email]>: >>>>>>> >>>>>>> >>>>>>>> I just went through all VW monolithic VMs from 2.0 to 7.7.1 with >>>>>>>> Dependency Walker: >>>>>>>> >>>>>>>> 2.0 and 2.5 statically linked any functions they called from >>>>>>>> msvcrt.dll >>>>>>>> >>>>>>>> 3.0 dynamically linked msvcrt40.dll, but 3.0b already changed that >>>>>>>> to just msvcrt.dll. >>>>>>>> >>>>>>>> 5i.3 - 7.7.1 have all dynamically linked msvcrt.dll, which has been >>>>>>>> an obligatory part of standard Windows installs for over a decade >>>>>>>> <http://en.wikipedia.org/wiki/Microsoft_Windows_library_files#Msvcrt >>>>>>>> .dll >>>>>>>> >>>>>>>>> (Windows 2000 on), in Windows\system32 (and before that part of a >>>>>>>>> >>>>>>>> normal Windows install since at least Windows 95 >>>>>>>> <http://support.microsoft.com/kb/895959> ). >>>>>>>> >>>>>>>> >>>>>>>> There's a big difference >>>>>>>> <http://msdn.microsoft.com/en- >>>>>>>> >>>>> us/library/abx4dbyh(VS.71).aspx#CodeSp >>>>> >>>>>>>> ippe >>>>>>>> t0> between msvcrt.dll (a system file) and msvcr[71-100].dll. The >>>>>>>> former is guaranteed to be found (although you have no control over >>>>>>>> the exact version), the latter must be installed with your application. >>>>>>>> >>>>>>>> >>>>>>>> In theory you shouldn't rely on the system msvcrt.dll, since it will >>>>>>>> be a different version from what you used in your own testing, but >>>>>>>> in practice for VW this seems to have worked well. I imagine VW's >>>>>>>> reliance is pretty generic and stable, so it's been more likely that >>>>>>>> things improved when MS shipped an update to msvcrt.dll, than that >>>>>>>> things would break. XP SP2 was the exception, as the significant >>>>>>>> changes it introduced caused problems in many applications. It looks >>>>>>>> like Microsoft are moving away from allowing 3rd party apps to >>>>>>>> dynamically link to the system msvcrt.dll, so Cincom should stop >>>>>>>> too. There's a good discussion >>>>>>>> <http://stackoverflow.com/questions/1073509/should-i-redistribute-ms >>>>>>>> vcrt >>>>>>>> -dll-with-my-application> on the pros and cons on StackOverflow. >>>>>>>> >>>>>>>> >>>>>>>> So, with the exception of 3.0 (which was corrected in 3.0b), no >>>>>>>> previous VM has dynamically depended on a particular >>>>>>>> msvcr[40-100].dll. Those particular DLLs aren't shipped with >>>>>>>> Windows, and if you depend on them you MUST ship them. >>>>>>>> >>>>>>>> >>>>>>>> Better though would be to statically link the CRT for the 64-bit VM, >>>>>>>> using /MT. That would also seem to be good advice for the 32-bit VM, >>>>>>>> to remove the dependency on the system msvcrt.dll. Statically >>>>>>>> linking the 64-bit VM will also significantly reduce the total size >>>>>>>> of the application, since I imagine VW only uses a tiny fraction of >>>>>>>> the whole msvcrt100.dll. >>>>>>>> >>>>>>>> >>>>>>>> Cheers, >>>>>>>> >>>>>>>> Steve >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> From: [hidden email] [mailto:vw-dev- >>>>>>>> >>>>> [hidden email]] >>>>> >>>>>>>> On Behalf Of Alan Knight >>>>>>>> Sent: 11. helmikuuta 2011 1:34 >>>>>>>> To: [hidden email] >>>>>>>> Subject: Re: vw7.8 64-bit on windows error >>>>>>>> >>>>>>>> >>>>>>>> I don't think we have statically linked the MSVCR libraries in >>>>>>>> previous versions, at least not for a very long time. I also don't >>>>>>>> think that those libraries are part of the Windows installs, but >>>>>>>> they tended to be there if you'd installed anything at all. And >>>>>>>> possibly if the operating system included programs that were built >>>>>>>> with those compilers they would be for practical purposes included. >>>>>>>> The difference in this case is, I suspect, that people have fewer >>>>>>>> things installed that are 64-bit applications, and the compiler is newer. >>>>>>>> >>>>>>>> It is not needed on 32-bit installations, because we are for the >>>>>>>> moment still using an older compiler version for the 32-bit >>>>>>>> versions, partly because of that dependency. Building the 64-bit >>>>>>>> versions required the use of the more recent compiler. 32-bit >>>>>>>> versions appear to my untrained eye to require MSVCRT.DLL with no >>>>>>>> version number embedded in the name. I don't believe it makes any >>>>>>>> >>>>> difference between visual.exe and vwnt.exe. >>>>> >>>>>>>> It's possible that we really ought to be installing it, but it is >>>>>>>> not something we've ever done in the past and it does not seem to >>>>>>>> have previously been an issue. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> In earlier versions, the necessary parts of the MSVCR library have >>>>>>>> been statically linked (IIRC), or then the relevant library has been >>>>>>>> part of a normal Windows installation anyway (maybe in IE?). Even >>>>>>>> the Cairo DLL was kindly made by Travis to be statically linked >>>>>>>> rather than require >>>>>>>> MSCVR90.dll: >>>>>>>> >>>>>>>> http://www.parcplace.net/list/vwnc-archive/0910/msg00085.html >>>>>>>> >>>>>>>> Information on static linking and msvcr100.dll is in the last >>>>>>>> message >>>>>>>> here: >>>>>>>> >>>>>>>> >>>>>>>> >>>>> http://social.msdn.microsoft.com/Forums/en/vssetup/thread/6891665f-f >>>>> >>>>>>>> d83- >>>>>>>> 426a-9d73-69d6d7e171a3 >>>>>>>> >>>>>>>> >>>>>>>> As Martin said, a vendor using a redistributable dynamically linked >>>>>>>> library like this is expected to ship it as part of their installer >>>>>>>> - as can be seen from e.g. InstallShield, which comes with a wide >>>>>>>> range of redistributables that install builders can add to their >>>>>>>> install. It's also what Microsoft says to do (IIUC): >>>>>>>> >>>>>>>> http://msdn.microsoft.com/en-us/library/ms235299.aspx >>>>>>>> >>>>>>>> "If you use a merge module that contains a Visual C++ DLL, you must >>>>>>>> include it in the Windows Installer package (or similar installation >>>>>>>> package) that you are using to deploy the application" >>>>>>>> >>>>>>>> >>>>>>>> Of course, all this is just for what Cincom should do when providing >>>>>>>> their product, if that product were just an application. Given the >>>>>>>> product in this case is a development environment, Cincom should >>>>>>>> also provide automation and/or instructions for developers to create >>>>>>>> and deploy their own products - including any necessary >>>>>>>> >>>>> redistributables. >>>>> >>>>>>>> Otherwise end users are going to be reporting that the application >>>>>>>> doesn't work, and developers aren't going to understand why (and >>>>>>>> presumably Cincom isn't going to get any royalties in that case!). >>>>>>>> >>>>>>>> >>>>>>>> Is msvcr100.dll also needed on 32-bit VW 7.8 installations on Windows? >>>>>>>> Does it make a difference if we use the monolithic visual.exe VM or >>>>>>>> the split .exe+.dll VM? >>>>>>>> >>>>>>>> >>>>>>>> Cheers, >>>>>>>> >>>>>>>> Steve >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> ________________________________ >>>>>>>> >>>>>>>> From: [hidden email] on behalf of Alan Knight >>>>>>>> Sent: Thu 10/02/2011 19:55 >>>>>>>> To: Martin McClure >>>>>>>> Cc: [hidden email] >>>>>>>> Subject: Re: vw7.8 64-bit on windows error >>>>>>>> >>>>>>>> >>>>>>>> That isn't something we've done in the past. I think that typically >>>>>>>> those libraries end up installed quite widely as soon as you've >>>>>>>> installed anything. And it would be a bit tricky, in that it >>>>>>>> wouldn't be integrated with our installation mechanisms. I think >>>>>>>> about the best we could do at this point would be to include a copy >>>>>>>> on the CD or download and people would have to install it >>>>>>>> themselves. We can also look into trying to do something in the next >>>>>>>> release when we expect to have Win64 as fully supported, but it's quite >>>>>>>> >>>>> late to try much for this one. >>>>> >>>>>>>> On 2011-02-10 12:09 AM, Martin McClure wrote: >>>>>>>> >>>>>>>>> On 02/09/11 11:11, Alan Knight wrote: >>>>>>>>> >>>>>>>>>> you need to install the appropriate MS runtime for the most recent >>>>>>>>>> compiler. >>>>>>>>>> >>>>>>>>> I'd gotten the impression that Microsoft's intent is that when an >>>>>>>>> application requires a particular version of the MSVCR library, the >>>>>>>>> application vendor should ship that MSVCR library along with the >>>>>>>>> application. >>>>>>>>> >>>>>>>>> Would it be possible to include that with the Windows install? >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> >>>>>>>>> -Martin >>>>>>>>> >>>>>>>> -- >>>>>>>> Alan Knight [|], Engineering Manager, Cincom Smalltalk >>>>>>>> [hidden email] [hidden email] http://www.cincomsmalltalk.com >>>>>>>> <http://www.cincomsmalltalk.com/> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>> _______________________________________________ >>>>> vwnc mailing list >>>>> [hidden email] >>>>> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc >>>>> >>>>> >>>> >>>> >>>> _______________________________________________ >>>> vwnc mailing list >>>> [hidden email] >>>> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc >>>> >>>> >>>> >>> >>> >> >> _______________________________________________ >> vwnc mailing list >> [hidden email] >> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: [now vw7.9] msvcr100.dll Re: vw7.8 64-bit on windowserror
|
|
In reply to this post by Christian Haider
Thanks for the tip. I am aware that, one day I will have to go that way (also for automatic updating and signing etc.), but it has been very easy for me and the users so far with the single file...
> -----Ursprüngliche Nachricht----- > Von: [hidden email] [mailto:[hidden email]] Im > Auftrag von James Robertson > Gesendet: Sonntag, 15. Juli 2012 19:31 > An: VWNC NC > Betreff: Re: [vwnc] [now vw7.9] msvcr100.dll Re: vw7.8 64-bit on > windowserror > > For BottomFeeder (many moons ago now), I started using the Nullsoft > installer. It was very, very easy to script. Unless you have a real need to go > insane, I'd avoid the MS installer.... > > > On Jul 15, 2012, at 10:22 AM, Christian Haider wrote: > > > Well, I deploy as a single file as documented in the AppDevGuide on page > 21-3 and $VISUALWORKS\packaging\win\WindowsPackaging.txt. > > > > I really like that, since I don't need a full installer and my clients just > download a zip file, unpack the .exe and put it wherever they like (server > directory, desktop or even a USB-stick or CD-ROM) and just run it. > > > > With the new DLL regime, I guess, that this deployment strategy is obsolete > and one needs to do the full installer dance... (I have not gotten the 7.9 yet, > so I don't know if the single file deployment doc section is still in place which > would be wrong then...). > > > > James - if you have only one file to deploy, any additional file stops the > show... > > > > Christian > > > >> -----Ursprüngliche Nachricht----- > >> Von: [hidden email] [mailto:[hidden email]] Im > >> Auftrag von James Robertson > >> Gesendet: Sonntag, 15. Juli 2012 15:31 > >> An: VWNC NC > >> Betreff: Re: [vwnc] [now vw7.9] msvcr100.dll Re: vw7.8 64-bit on > >> windowserror > >> > >> While I enjoy simple deployments as much as the next guy, I'm not > >> sure how this qualifies as a showstopper. I developed the build tool > >> we use at my current job; when we end up in 7.9, I'll have the change > >> a batch file to copy this file from a known location (a copy will end > >> up being kept with a few other files we need in the image dir) to the > deployment directory. > >> > >> Static linking was something that used to be done with database dlls > >> way, way back in the day, and it caused problems - people ended up > >> being stuck on specific revs of the various databases ParcPlace supported. > >> > >> How does adding one file to your install procedure cause that much > >> heartburn? > >> > >> On Jul 15, 2012, at 4:09 AM, Christian Haider wrote: > >> > >>> Yes, this is going to be a show-stopper for using VW 7.9 for me as > >>> well :-( > >>> > >>> But since linking the DLLs statically to the VMs for Windows needs > >>> to be > >> done only once, maybe somebody did this and could share the VM with > >> the community? > >>> > >>> I wonder why Cincom is not able to provide such a VM... Is it so > >>> hard to do > >> or are there legal issues involved? > >>> > >>> I really hope that there will be a practical solution to this > >>> problem without > >> having to dive into C land to figure out how to do that myself... > >>> > >>> Christian > >>> > >>>> -----Ursprüngliche Nachricht----- > >>>> Von: [hidden email] [mailto:[hidden email]] > Im > >>>> Auftrag von Carl Gundel > >>>> Gesendet: Sonntag, 15. Juli 2012 06:31 > >>>> An: VWNC List > >>>> Betreff: [vwnc] [now vw7.9] msvcr100.dll Re: vw7.8 64-bit on > >>>> windows error > >>>> > >>>>> From the 7.9 release notes: > >>>> > >>>> "Windows OE DLL Requirement > >>>> Due to a compiler upgrade, the Windows VMs require that > >>>> msvcr100.dll be installed in its proper location (System32 or > >>>> SysWOW64).If this DLL is not already installed, the installer > >>>> installs and runs a program (VisualWorks32bitDLLPrereqs, and > >>>> VisualWorks64bitDLLPrereqs on 64-bit > >>>> systems) that installs the DLL(s) and registers VisualWorks' > >>>> interest in > >> them. > >>>> After installation, an information screen tells you this has been > >>>> done. If you uninstall this program, VisualWorks is deregistered > >>>> for it, and the DLL is removed if no other program has an interest. > >>>> When deploying an application with the VM, you are responsible for > >>>> ensuring that this file is present on the target system." > >>>> > >>>> So, this is now required for 32-bit VisualWorks on Windows also? > >>>> > >>>> This is going to be very, very inconvenient for me. The single > >>>> file VM and the ability to embed the image in the VM are one of the > >>>> reasons I chose VisualWorks. Up to this point I have not needed > >>>> any extra libraries and this is very important to me and to my > customers. > >>>> The msvcr100.dll throws a real monkey wrench into things for me. I > >>>> hope that Cincom will decide to statically link whatever functions > >>>> it needs from this DLL going forward. I may be forced to stick > >>>> with 7.8 > >> otherwise. > >>>> > >>>> -Carl Gundel > >>>> http://www.libertybasic.com > >>>> http://www.runbasic.com > >>>> > >>>> On Sun, Feb 20, 2011 at 10:29 AM, Alan Knight <[hidden email]> > wrote: > >>>>> > >>>>> Yes, this is expected. We'll need to do something about that, but > >>>>> for 7.8, where win64 is in preview, I think it's likely to remain > >>>>> and we'll sort out the various possibilities with a bit more time > >>>>> to > >> consider. > >>>>> > >>>>> > >>>>> On 11-02-20 6:36 AM, Steffen Märcker wrote: > >>>>>> > >>>>>> > >>>>>> I've just attempted to start the win64 vm on Windows 7 Prof. 64 > >>>>>> Bit and got the message to install msvcr100.dll too. Do I > >>>>>> understand this thread right that this is actually expected? > >>>>>> > >>>>>> Regards, Steffen > >>>>>> > >>>>>> > >>>>>> Am 11.02.2011, 11:17 Uhr, schrieb Steven Kelly > >> <[hidden email]>: > >>>>>> > >>>>>>> I just went through all VW monolithic VMs from 2.0 to 7.7.1 with > >>>>>>> Dependency Walker: > >>>>>>> > >>>>>>> 2.0 and 2.5 statically linked any functions they called from > >>>>>>> msvcrt.dll > >>>>>>> > >>>>>>> 3.0 dynamically linked msvcrt40.dll, but 3.0b already changed > >>>>>>> that to just msvcrt.dll. > >>>>>>> > >>>>>>> 5i.3 - 7.7.1 have all dynamically linked msvcrt.dll, which has > >>>>>>> been an obligatory part of standard Windows installs for over a > >>>>>>> decade > >>>>>>> > >> <http://en.wikipedia.org/wiki/Microsoft_Windows_library_files#Msvc > >>>>>>> rt > >>>>>>> .dll > >>>>>>>> > >>>>>>>> (Windows 2000 on), in Windows\system32 (and before that part > of > >>>>>>>> a > >>>>>>> > >>>>>>> normal Windows install since at least Windows 95 > >>>>>>> <http://support.microsoft.com/kb/895959> ). > >>>>>>> > >>>>>>> > >>>>>>> There's a big difference > >>>>>>> <http://msdn.microsoft.com/en- > >>>> us/library/abx4dbyh(VS.71).aspx#CodeSp > >>>>>>> ippe > >>>>>>> t0> between msvcrt.dll (a system file) and msvcr[71-100].dll. > >>>>>>> t0> The > >>>>>>> former is guaranteed to be found (although you have no control > >>>>>>> over the exact version), the latter must be installed with your > >> application. > >>>>>>> > >>>>>>> > >>>>>>> In theory you shouldn't rely on the system msvcrt.dll, since it > >>>>>>> will be a different version from what you used in your own > >>>>>>> testing, but in practice for VW this seems to have worked well. > >>>>>>> I imagine VW's reliance is pretty generic and stable, so it's > >>>>>>> been more likely that things improved when MS shipped an update > >>>>>>> to msvcrt.dll, than that things would break. XP SP2 was the > >>>>>>> exception, as the significant changes it introduced caused > >>>>>>> problems in many applications. It looks like Microsoft are > >>>>>>> moving away from allowing 3rd party apps to dynamically link to > >>>>>>> the system msvcrt.dll, so Cincom should stop too. There's a good > >>>>>>> discussion > >>>>>>> <http://stackoverflow.com/questions/1073509/should-i-redistribut > >>>>>>> e- > >>>>>>> ms > >>>>>>> vcrt > >>>>>>> -dll-with-my-application> on the pros and cons on StackOverflow. > >>>>>>> > >>>>>>> > >>>>>>> So, with the exception of 3.0 (which was corrected in 3.0b), no > >>>>>>> previous VM has dynamically depended on a particular > >>>>>>> msvcr[40-100].dll. Those particular DLLs aren't shipped with > >>>>>>> Windows, and if you depend on them you MUST ship them. > >>>>>>> > >>>>>>> > >>>>>>> Better though would be to statically link the CRT for the 64-bit > >>>>>>> VM, using /MT. That would also seem to be good advice for the > >>>>>>> 32-bit VM, to remove the dependency on the system msvcrt.dll. > >>>>>>> Statically linking the 64-bit VM will also significantly reduce > >>>>>>> the total size of the application, since I imagine VW only uses > >>>>>>> a tiny fraction of the whole msvcrt100.dll. > >>>>>>> > >>>>>>> > >>>>>>> Cheers, > >>>>>>> > >>>>>>> Steve > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> From: [hidden email] [mailto:vw-dev- > >>>> [hidden email]] > >>>>>>> On Behalf Of Alan Knight > >>>>>>> Sent: 11. helmikuuta 2011 1:34 > >>>>>>> To: [hidden email] > >>>>>>> Subject: Re: vw7.8 64-bit on windows error > >>>>>>> > >>>>>>> > >>>>>>> I don't think we have statically linked the MSVCR libraries in > >>>>>>> previous versions, at least not for a very long time. I also > >>>>>>> don't think that those libraries are part of the Windows > >>>>>>> installs, but they tended to be there if you'd installed > >>>>>>> anything at all. And possibly if the operating system included > >>>>>>> programs that were built with those compilers they would be for > practical purposes included. > >>>>>>> The difference in this case is, I suspect, that people have > >>>>>>> fewer things installed that are 64-bit applications, and the compiler > is newer. > >>>>>>> > >>>>>>> It is not needed on 32-bit installations, because we are for the > >>>>>>> moment still using an older compiler version for the 32-bit > >>>>>>> versions, partly because of that dependency. Building the 64-bit > >>>>>>> versions required the use of the more recent compiler. 32-bit > >>>>>>> versions appear to my untrained eye to require MSVCRT.DLL with > >>>>>>> no version number embedded in the name. I don't believe it makes > >>>>>>> any > >>>> difference between visual.exe and vwnt.exe. > >>>>>>> > >>>>>>> It's possible that we really ought to be installing it, but it > >>>>>>> is not something we've ever done in the past and it does not > >>>>>>> seem to have previously been an issue. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> In earlier versions, the necessary parts of the MSVCR library > >>>>>>> have been statically linked (IIRC), or then the relevant library > >>>>>>> has been part of a normal Windows installation anyway (maybe in > IE?). > >>>>>>> Even the Cairo DLL was kindly made by Travis to be statically > >>>>>>> linked rather than require > >>>>>>> MSCVR90.dll: > >>>>>>> > >>>>>>> http://www.parcplace.net/list/vwnc-archive/0910/msg00085.html > >>>>>>> > >>>>>>> Information on static linking and msvcr100.dll is in the last > >>>>>>> message > >>>>>>> here: > >>>>>>> > >>>>>>> > >>>> > http://social.msdn.microsoft.com/Forums/en/vssetup/thread/6891665f- > >>>> f > >>>>>>> d83- > >>>>>>> 426a-9d73-69d6d7e171a3 > >>>>>>> > >>>>>>> > >>>>>>> As Martin said, a vendor using a redistributable dynamically > >>>>>>> linked library like this is expected to ship it as part of their > >>>>>>> installer > >>>>>>> - as can be seen from e.g. InstallShield, which comes with a > >>>>>>> wide range of redistributables that install builders can add to > >>>>>>> their install. It's also what Microsoft says to do (IIUC): > >>>>>>> > >>>>>>> http://msdn.microsoft.com/en-us/library/ms235299.aspx > >>>>>>> > >>>>>>> "If you use a merge module that contains a Visual C++ DLL, you > >>>>>>> must include it in the Windows Installer package (or similar > >>>>>>> installation > >>>>>>> package) that you are using to deploy the application" > >>>>>>> > >>>>>>> > >>>>>>> Of course, all this is just for what Cincom should do when > >>>>>>> providing their product, if that product were just an application. > >>>>>>> Given the product in this case is a development environment, > >>>>>>> Cincom should also provide automation and/or instructions for > >>>>>>> developers to create and deploy their own products - including > >>>>>>> any necessary > >>>> redistributables. > >>>>>>> Otherwise end users are going to be reporting that the > >>>>>>> application doesn't work, and developers aren't going to > >>>>>>> understand why (and presumably Cincom isn't going to get any > royalties in that case!). > >>>>>>> > >>>>>>> > >>>>>>> Is msvcr100.dll also needed on 32-bit VW 7.8 installations on > >> Windows? > >>>>>>> Does it make a difference if we use the monolithic visual.exe VM > >>>>>>> or the split .exe+.dll VM? > >>>>>>> > >>>>>>> > >>>>>>> Cheers, > >>>>>>> > >>>>>>> Steve > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> ________________________________ > >>>>>>> > >>>>>>> From: [hidden email] on behalf of Alan Knight > >>>>>>> Sent: Thu 10/02/2011 19:55 > >>>>>>> To: Martin McClure > >>>>>>> Cc: [hidden email] > >>>>>>> Subject: Re: vw7.8 64-bit on windows error > >>>>>>> > >>>>>>> > >>>>>>> That isn't something we've done in the past. I think that > >>>>>>> typically those libraries end up installed quite widely as soon > >>>>>>> as you've installed anything. And it would be a bit tricky, in > >>>>>>> that it wouldn't be integrated with our installation mechanisms. > >>>>>>> I think about the best we could do at this point would be to > >>>>>>> include a copy on the CD or download and people would have to > >>>>>>> install it themselves. We can also look into trying to do > >>>>>>> something in the next release when we expect to have Win64 as > >>>>>>> fully supported, but it's quite > >>>> late to try much for this one. > >>>>>>> > >>>>>>> On 2011-02-10 12:09 AM, Martin McClure wrote: > >>>>>>>> > >>>>>>>> On 02/09/11 11:11, Alan Knight wrote: > >>>>>>>>> > >>>>>>>>> you need to install the appropriate MS runtime for the most > >>>>>>>>> recent compiler. > >>>>>>>> > >>>>>>>> I'd gotten the impression that Microsoft's intent is that when > >>>>>>>> an application requires a particular version of the MSVCR > >>>>>>>> library, the application vendor should ship that MSVCR library > >>>>>>>> along with the application. > >>>>>>>> > >>>>>>>> Would it be possible to include that with the Windows install? > >>>>>>>> > >>>>>>>> Regards, > >>>>>>>> > >>>>>>>> -Martin > >>>>>>> > >>>>>>> > >>>>>>> -- > >>>>>>> Alan Knight [|], Engineering Manager, Cincom Smalltalk > >>>>>>> [hidden email] [hidden email] > >> http://www.cincomsmalltalk.com > >>>>>>> <http://www.cincomsmalltalk.com/> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>> > >>>> > >>>> _______________________________________________ > >>>> vwnc mailing list > >>>> [hidden email] > >>>> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > >>>> > >>> > >>> > >>> _______________________________________________ > >>> vwnc mailing list > >>> [hidden email] > >>> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > >> > >> James Robertson > >> http://www.jarober.com > >> [hidden email] > >> > >> > >> > >> > >> _______________________________________________ > >> vwnc mailing list > >> [hidden email] > >> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > >> > > > > James Robertson > http://www.jarober.com > [hidden email] > > > > > _______________________________________________ > vwnc mailing list > [hidden email] > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: [now vw7.9] msvcr100.dll Re: vw7.8 64-bit on windows error
|
|
In reply to this post by Christian Haider
Thanks Niall for the clarification.
In essence this means that Cincom will not provide a one file deployment option and I will be stuck with 7.8.1 (the second option is not really interesting since it puts the burden on the user to find out and decide what to do with the second file - then the installer option would be simpler for the users). But if the DLL can be installed locally along the .exe, what about putting it into the .exe with Reshacker? When the image can find the VM, why can't the VM find the DLL in there? I think I heard that a long time ago that this could be possible. Does anybody know about this? Christian > -----Ursprüngliche Nachricht----- > Von: Niall Ross [mailto:[hidden email]] > Gesendet: Montag, 16. Juli 2012 00:01 > An: Christian Haider; [hidden email]; [hidden email] > Cc: VWNC List > Betreff: Re: [vwnc] [now vw7.9] msvcr100.dll Re: vw7.8 64-bit on windows > error > > Dear Carl, Christian, David et al, > the msvcr100.dll does not have to be installed in a system location. > > For example, the 7.9 VW installer puts it in the system location if it can write > to that location. If it cannot, it puts dll in VW's bin/win (and 64bit in > bin/win64). Similarly, any app installer can put the dll in the same location as > their VM or single file .exe. > > A local msvcr100.dll acts > > - as the one used by our VM if no system one is installed on that platform > > - as a softlink to the system one if present: our VM always uses the system > one if present > > As of VS2010, Microsoft no longer include the dll in its base platforms. This is > the change we are responding to - the corresponding prior versions have > always been there by default so we never had to install them. (Actually, the > dll is there,but hidden, only for MS internal stuff and not promised to remain > compatible.) Thus the VS2010 and later dll has to be either > - installed in system > or > - installed locally > or > - statically linked > > So the corresponding single-file .exe options are: > > a) "the full install dance" - almost certainly what you don't want to do if > you're using the single file option > > b) Have your zip expand to YourApp.exe and msvcr100.dll, not just > YourApp.exe. As noted, if your customer later installs or upgrade a system > msvcr100.dll, it will all still work. (If you want, you can have your installation > notes tell the user: "If you can put our msvcr100.dll in the bin and the .exe > still works, leave it in the bin - you don't need it." This merely saves them > ~750K of space; no other point.) > > c) Statically-link the dll to the VM: the difference from (b) is that if the user > upgrades their platform, you will not upgrade with it, so we're not starting by > encouraging this option. We're hoping our customers will say that (b) is OK. > > (The relevant Microsoft team promise future backward compatibility of the > dll in all cases but discovery of major security hole.) > > HTH > Niall Ross > > > >Yes, this is going to be a show-stopper for using VW 7.9 for me as well > >:-( > > > >But since linking the DLLs statically to the VMs for Windows needs to be > done only once, maybe somebody did this and could share the VM with the > community? > > > >I wonder why Cincom is not able to provide such a VM... Is it so hard to do > or are there legal issues involved? > > > >I really hope that there will be a practical solution to this problem without > having to dive into C land to figure out how to do that myself... > > > >Christian > > > > > > > >>-----Ursprüngliche Nachricht----- > >>Von: [hidden email] [mailto:[hidden email]] Im > >>Auftrag von Carl Gundel > >>Gesendet: Sonntag, 15. Juli 2012 06:31 > >>An: VWNC List > >>Betreff: [vwnc] [now vw7.9] msvcr100.dll Re: vw7.8 64-bit on windows > >>error > >> > >>>From the 7.9 release notes: > >> > >>"Windows OE DLL Requirement > >>Due to a compiler upgrade, the Windows VMs require that msvcr100.dll > >>be installed in its proper location (System32 or SysWOW64).If this DLL > >>is not already installed, the installer installs and runs a program > >>(VisualWorks32bitDLLPrereqs, and VisualWorks64bitDLLPrereqs on 64-bit > >>systems) that installs the DLL(s) and registers VisualWorks' interest in > them. > >>After installation, an information screen tells you this has been > >>done. If you uninstall this program, VisualWorks is deregistered for > >>it, and the DLL is removed if no other program has an interest. > >>When deploying an application with the VM, you are responsible for > >>ensuring that this file is present on the target system." > >> > >>So, this is now required for 32-bit VisualWorks on Windows also? > >> > >>This is going to be very, very inconvenient for me. The single file > >>VM and the ability to embed the image in the VM are one of the reasons > >>I chose VisualWorks. Up to this point I have not needed any extra > >>libraries and this is very important to me and to my customers. The > >>msvcr100.dll throws a real monkey wrench into things for me. I hope > >>that Cincom will decide to statically link whatever functions it needs > >>from this DLL going forward. I may be forced to stick with 7.8 otherwise. > >> > >>-Carl Gundel > >>http://www.libertybasic.com > >>http://www.runbasic.com > >> > >>On Sun, Feb 20, 2011 at 10:29 AM, Alan Knight <[hidden email]> wrote: > >> > >> > >>>Yes, this is expected. We'll need to do something about that, but for > >>>7.8, where win64 is in preview, I think it's likely to remain and > >>>we'll sort out the various possibilities with a bit more time to consider. > >>> > >>> > >>>On 11-02-20 6:36 AM, Steffen Märcker wrote: > >>> > >>> > >>>>I've just attempted to start the win64 vm on Windows 7 Prof. 64 Bit > >>>>and got the message to install msvcr100.dll too. Do I understand > >>>>this thread right that this is actually expected? > >>>> > >>>>Regards, Steffen > >>>> > >>>> > >>>>Am 11.02.2011, 11:17 Uhr, schrieb Steven Kelly > <[hidden email]>: > >>>> > >>>> > >>>> > >>>>>I just went through all VW monolithic VMs from 2.0 to 7.7.1 with > >>>>>Dependency Walker: > >>>>> > >>>>>2.0 and 2.5 statically linked any functions they called from > >>>>>msvcrt.dll > >>>>> > >>>>>3.0 dynamically linked msvcrt40.dll, but 3.0b already changed that > >>>>>to just msvcrt.dll. > >>>>> > >>>>>5i.3 - 7.7.1 have all dynamically linked msvcrt.dll, which has been > >>>>>an obligatory part of standard Windows installs for over a decade > >>>>><http://en.wikipedia.org/wiki/Microsoft_Windows_library_files#Msv > cr > >>>>>t > >>>>>.dll > >>>>> > >>>>> > >>>>>> (Windows 2000 on), in Windows\system32 (and before that part of a > >>>>>> > >>>>>> > >>>>>normal Windows install since at least Windows 95 > >>>>><http://support.microsoft.com/kb/895959> ). > >>>>> > >>>>> > >>>>>There's a big difference > >>>>><http://msdn.microsoft.com/en- > >>>>> > >>>>> > >>us/library/abx4dbyh(VS.71).aspx#CodeSp > >> > >> > >>>>>ippe > >>>>>t0> between msvcrt.dll (a system file) and msvcr[71-100].dll. The > >>>>>former is guaranteed to be found (although you have no control over > >>>>>the exact version), the latter must be installed with your application. > >>>>> > >>>>> > >>>>>In theory you shouldn't rely on the system msvcrt.dll, since it > >>>>>will be a different version from what you used in your own testing, > >>>>>but in practice for VW this seems to have worked well. I imagine > >>>>>VW's reliance is pretty generic and stable, so it's been more > >>>>>likely that things improved when MS shipped an update to > >>>>>msvcrt.dll, than that things would break. XP SP2 was the exception, > >>>>>as the significant changes it introduced caused problems in many > >>>>>applications. It looks like Microsoft are moving away from allowing > >>>>>3rd party apps to dynamically link to the system msvcrt.dll, so > >>>>>Cincom should stop too. There's a good discussion > >>>>><http://stackoverflow.com/questions/1073509/should-i-redistribute- > m > >>>>>s > >>>>>vcrt > >>>>>-dll-with-my-application> on the pros and cons on StackOverflow. > >>>>> > >>>>> > >>>>>So, with the exception of 3.0 (which was corrected in 3.0b), no > >>>>>previous VM has dynamically depended on a particular > >>>>>msvcr[40-100].dll. Those particular DLLs aren't shipped with > >>>>>Windows, and if you depend on them you MUST ship them. > >>>>> > >>>>> > >>>>>Better though would be to statically link the CRT for the 64-bit > >>>>>VM, using /MT. That would also seem to be good advice for the > >>>>>32-bit VM, to remove the dependency on the system msvcrt.dll. > >>>>>Statically linking the 64-bit VM will also significantly reduce the > >>>>>total size of the application, since I imagine VW only uses a tiny > >>>>>fraction of the whole msvcrt100.dll. > >>>>> > >>>>> > >>>>>Cheers, > >>>>> > >>>>>Steve > >>>>> > >>>>> > >>>>> > >>>>>From: [hidden email] [mailto:vw-dev- > >>>>> > >>>>> > >>[hidden email]] > >> > >> > >>>>>On Behalf Of Alan Knight > >>>>>Sent: 11. helmikuuta 2011 1:34 > >>>>>To: [hidden email] > >>>>>Subject: Re: vw7.8 64-bit on windows error > >>>>> > >>>>> > >>>>>I don't think we have statically linked the MSVCR libraries in > >>>>>previous versions, at least not for a very long time. I also don't > >>>>>think that those libraries are part of the Windows installs, but > >>>>>they tended to be there if you'd installed anything at all. And > >>>>>possibly if the operating system included programs that were built > >>>>>with those compilers they would be for practical purposes included. > >>>>>The difference in this case is, I suspect, that people have fewer > >>>>>things installed that are 64-bit applications, and the compiler is newer. > >>>>> > >>>>>It is not needed on 32-bit installations, because we are for the > >>>>>moment still using an older compiler version for the 32-bit > >>>>>versions, partly because of that dependency. Building the 64-bit > >>>>>versions required the use of the more recent compiler. 32-bit > >>>>>versions appear to my untrained eye to require MSVCRT.DLL with no > >>>>>version number embedded in the name. I don't believe it makes any > >>>>> > >>>>> > >>difference between visual.exe and vwnt.exe. > >> > >> > >>>>>It's possible that we really ought to be installing it, but it is > >>>>>not something we've ever done in the past and it does not seem to > >>>>>have previously been an issue. > >>>>> > >>>>> > >>>>> > >>>>>In earlier versions, the necessary parts of the MSVCR library have > >>>>>been statically linked (IIRC), or then the relevant library has > >>>>>been part of a normal Windows installation anyway (maybe in IE?). > >>>>>Even the Cairo DLL was kindly made by Travis to be statically > >>>>>linked rather than require > >>>>>MSCVR90.dll: > >>>>> > >>>>>http://www.parcplace.net/list/vwnc-archive/0910/msg00085.html > >>>>> > >>>>>Information on static linking and msvcr100.dll is in the last > >>>>>message > >>>>>here: > >>>>> > >>>>> > >>>>> > >>>>> > >>http://social.msdn.microsoft.com/Forums/en/vssetup/thread/6891665f-f > >> > >> > >>>>>d83- > >>>>>426a-9d73-69d6d7e171a3 > >>>>> > >>>>> > >>>>>As Martin said, a vendor using a redistributable dynamically linked > >>>>>library like this is expected to ship it as part of their installer > >>>>>- as can be seen from e.g. InstallShield, which comes with a wide > >>>>>range of redistributables that install builders can add to their > >>>>>install. It's also what Microsoft says to do (IIUC): > >>>>> > >>>>>http://msdn.microsoft.com/en-us/library/ms235299.aspx > >>>>> > >>>>>"If you use a merge module that contains a Visual C++ DLL, you must > >>>>>include it in the Windows Installer package (or similar > >>>>>installation > >>>>>package) that you are using to deploy the application" > >>>>> > >>>>> > >>>>>Of course, all this is just for what Cincom should do when > >>>>>providing their product, if that product were just an application. > >>>>>Given the product in this case is a development environment, Cincom > >>>>>should also provide automation and/or instructions for developers > >>>>>to create and deploy their own products - including any necessary > >>>>> > >>>>> > >>redistributables. > >> > >> > >>>>>Otherwise end users are going to be reporting that the application > >>>>>doesn't work, and developers aren't going to understand why (and > >>>>>presumably Cincom isn't going to get any royalties in that case!). > >>>>> > >>>>> > >>>>>Is msvcr100.dll also needed on 32-bit VW 7.8 installations on Windows? > >>>>>Does it make a difference if we use the monolithic visual.exe VM or > >>>>>the split .exe+.dll VM? > >>>>> > >>>>> > >>>>>Cheers, > >>>>> > >>>>>Steve > >>>>> > >>>>> > >>>>> > >>>>>________________________________ > >>>>> > >>>>>From: [hidden email] on behalf of Alan Knight > >>>>>Sent: Thu 10/02/2011 19:55 > >>>>>To: Martin McClure > >>>>>Cc: [hidden email] > >>>>>Subject: Re: vw7.8 64-bit on windows error > >>>>> > >>>>> > >>>>>That isn't something we've done in the past. I think that typically > >>>>>those libraries end up installed quite widely as soon as you've > >>>>>installed anything. And it would be a bit tricky, in that it > >>>>>wouldn't be integrated with our installation mechanisms. I think > >>>>>about the best we could do at this point would be to include a copy > >>>>>on the CD or download and people would have to install it > >>>>>themselves. We can also look into trying to do something in the > >>>>>next release when we expect to have Win64 as fully supported, but > >>>>>it's quite > >>>>> > >>>>> > >>late to try much for this one. > >> > >> > >>>>>On 2011-02-10 12:09 AM, Martin McClure wrote: > >>>>> > >>>>> > >>>>>>On 02/09/11 11:11, Alan Knight wrote: > >>>>>> > >>>>>> > >>>>>>>you need to install the appropriate MS runtime for the most > >>>>>>>recent compiler. > >>>>>>> > >>>>>>> > >>>>>>I'd gotten the impression that Microsoft's intent is that when an > >>>>>>application requires a particular version of the MSVCR library, > >>>>>>the application vendor should ship that MSVCR library along with > >>>>>>the application. > >>>>>> > >>>>>>Would it be possible to include that with the Windows install? > >>>>>> > >>>>>>Regards, > >>>>>> > >>>>>>-Martin > >>>>>> > >>>>>> > >>>>>-- > >>>>>Alan Knight [|], Engineering Manager, Cincom Smalltalk > >>>>>[hidden email] [hidden email] > http://www.cincomsmalltalk.com > >>>>><http://www.cincomsmalltalk.com/> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>_______________________________________________ > >>vwnc mailing list > >>[hidden email] > >>http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > >> > >> > >> > > > > > >_______________________________________________ > >vwnc mailing list > >[hidden email] > >http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > > > > > > > > > > > _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: [now vw7.9] msvcr100.dll Re: vw7.8 64-bit onwindows error
|
|
ResHacker is for hacking resources into an .exe, and DLLs aren't resources. Putting a DLL into an .exe is called static linking, and can only happen at compile time - you can't do it after the fact. However, Cincom provides the VM source to (commercial?) customers, so you can statically link the DLL functions if you want. It just might be a lot of work for someone who doesn't work on the VM, or with Visual Studio and Windows C coding. I'd much rather see Cincom do that. I really appreciate the time Niall and others there have already spent on this issue. It's much more effective for the VW community if only Cincom need to know the details of these things - that's the promise of write once, deploy anywhere that is part of what makes VW attractive.
If VW is dynamically linked to msvcr100.dll, and we supply it in out app's directory, on many PCs VW will be the sole user of that DLL, so there won't be a system version that gets automatic updates from Microsoft. As paying customers, I don't think we should each separately have to follow security bulletins for 3rd party components used internally by Cincom. Cincom should monitor those, and provide updated VMs as necessary. (And yes, there have been security fixes for msvcr100.dll: http://support.microsoft.com/kb/2467173) I've asked before (on vw-dev 3.5.2012), but not got an answer: is there a technical showstopper preventing static linking of msvcr100.dll calls in visual.exe? We use Cairo, so that's another DLL we need to install anyway - and with 7.9, that changes to 4 Cairo DLLs. On the Mac, the equivalent .dylibs have swollen to 4.5 MB, from 1.66 MB in previous versions. If that's just symbols for debug info, hopefully Cincom can produce stripped dylibs for visual.app and debug ones for debug.app. All the best, Steve > -----Original Message----- > From: [hidden email] [mailto:[hidden email]] On > Behalf Of Christian Haider > Sent: 16. heinäkuuta 2012 10:15 > To: Niall Ross; [hidden email]; [hidden email] > Cc: VWNC List > Subject: Re: [vwnc] [now vw7.9] msvcr100.dll Re: vw7.8 64-bit onwindows > error > > Thanks Niall for the clarification. > > In essence this means that Cincom will not provide a one file > deployment option and I will be stuck with 7.8.1 (the second option is > not really interesting since it puts the burden on the user to find out > and decide what to do with the second file - then the installer option > would be simpler for the users). > > But if the DLL can be installed locally along the .exe, what about > putting it into the .exe with Reshacker? When the image can find the VM, > why can't the VM find the DLL in there? I think I heard that a long > time ago that this could be possible. Does anybody know about this? > > Christian > > > -----Ursprüngliche Nachricht----- > > Von: Niall Ross [mailto:[hidden email]] > > Gesendet: Montag, 16. Juli 2012 00:01 > > An: Christian Haider; [hidden email]; [hidden email] > > Cc: VWNC List > > Betreff: Re: [vwnc] [now vw7.9] msvcr100.dll Re: vw7.8 64-bit on > windows > > error > > > > Dear Carl, Christian, David et al, > > the msvcr100.dll does not have to be installed in a system > location. > > > > For example, the 7.9 VW installer puts it in the system location if > it can write > > to that location. If it cannot, it puts dll in VW's bin/win (and > 64bit in > > bin/win64). Similarly, any app installer can put the dll in the same > location as > > their VM or single file .exe. > > > > A local msvcr100.dll acts > > > > - as the one used by our VM if no system one is installed on that > platform > > > > - as a softlink to the system one if present: our VM always uses > the system > > one if present > > > > As of VS2010, Microsoft no longer include the dll in its base > platforms. This is > > the change we are responding to - the corresponding prior versions > have > > always been there by default so we never had to install them. > (Actually, the > > dll is there,but hidden, only for MS internal stuff and not promised > to remain > > compatible.) Thus the VS2010 and later dll has to be either > > - installed in system > > or > > - installed locally > > or > > - statically linked > > > > So the corresponding single-file .exe options are: > > > > a) "the full install dance" - almost certainly what you don't want to > do if > > you're using the single file option > > > > b) Have your zip expand to YourApp.exe and msvcr100.dll, not just > > YourApp.exe. As noted, if your customer later installs or upgrade a > system > > msvcr100.dll, it will all still work. (If you want, you can have > your installation > > notes tell the user: "If you can put our msvcr100.dll in the bin and > the .exe > > still works, leave it in the bin - you don't need it." This merely > saves them > > ~750K of space; no other point.) > > > > c) Statically-link the dll to the VM: the difference from (b) is > that if the user > > upgrades their platform, you will not upgrade with it, so we're not > starting by > > encouraging this option. We're hoping our customers will say that > (b) is OK. > > > > (The relevant Microsoft team promise future backward compatibility of > the > > dll in all cases but discovery of major security hole.) > > > > HTH > > Niall Ross > > > > > > >Yes, this is going to be a show-stopper for using VW 7.9 for me as > well > > >:-( > > > > > >But since linking the DLLs statically to the VMs for Windows needs > to be > > done only once, maybe somebody did this and could share the VM with > the > > community? > > > > > >I wonder why Cincom is not able to provide such a VM... Is it so > hard to do > > or are there legal issues involved? > > > > > >I really hope that there will be a practical solution to this > problem without > > having to dive into C land to figure out how to do that myself... > > > > > >Christian > > > > > > > > > > > >>-----Ursprüngliche Nachricht----- > > >>Von: [hidden email] [mailto:[hidden email]] Im > > >>Auftrag von Carl Gundel > > >>Gesendet: Sonntag, 15. Juli 2012 06:31 > > >>An: VWNC List > > >>Betreff: [vwnc] [now vw7.9] msvcr100.dll Re: vw7.8 64-bit on > windows > > >>error > > >> > > >>>From the 7.9 release notes: > > >> > > >>"Windows OE DLL Requirement > > >>Due to a compiler upgrade, the Windows VMs require that > msvcr100.dll > > >>be installed in its proper location (System32 or SysWOW64).If this > DLL > > >>is not already installed, the installer installs and runs a program > > >>(VisualWorks32bitDLLPrereqs, and VisualWorks64bitDLLPrereqs on 64- > bit > > >>systems) that installs the DLL(s) and registers VisualWorks' > interest in > > them. > > >>After installation, an information screen tells you this has been > > >>done. If you uninstall this program, VisualWorks is deregistered > for > > >>it, and the DLL is removed if no other program has an interest. > > >>When deploying an application with the VM, you are responsible for > > >>ensuring that this file is present on the target system." > > >> > > >>So, this is now required for 32-bit VisualWorks on Windows also? > > >> > > >>This is going to be very, very inconvenient for me. The single > file > > >>VM and the ability to embed the image in the VM are one of the > reasons > > >>I chose VisualWorks. Up to this point I have not needed any extra > > >>libraries and this is very important to me and to my customers. > The > > >>msvcr100.dll throws a real monkey wrench into things for me. I > hope > > >>that Cincom will decide to statically link whatever functions it > needs > > >>from this DLL going forward. I may be forced to stick with 7.8 > otherwise. > > >> > > >>-Carl Gundel > > >>http://www.libertybasic.com > > >>http://www.runbasic.com > > >> > > >>On Sun, Feb 20, 2011 at 10:29 AM, Alan Knight <[hidden email]> > wrote: > > >> > > >> > > >>>Yes, this is expected. We'll need to do something about that, but > for > > >>>7.8, where win64 is in preview, I think it's likely to remain and > > >>>we'll sort out the various possibilities with a bit more time to > consider. > > >>> > > >>> > > >>>On 11-02-20 6:36 AM, Steffen Märcker wrote: > > >>> > > >>> > > >>>>I've just attempted to start the win64 vm on Windows 7 Prof. 64 > Bit > > >>>>and got the message to install msvcr100.dll too. Do I understand > > >>>>this thread right that this is actually expected? > > >>>> > > >>>>Regards, Steffen > > >>>> > > >>>> > > >>>>Am 11.02.2011, 11:17 Uhr, schrieb Steven Kelly > > <[hidden email]>: > > >>>> > > >>>> > > >>>> > > >>>>>I just went through all VW monolithic VMs from 2.0 to 7.7.1 with > > >>>>>Dependency Walker: > > >>>>> > > >>>>>2.0 and 2.5 statically linked any functions they called from > > >>>>>msvcrt.dll > > >>>>> > > >>>>>3.0 dynamically linked msvcrt40.dll, but 3.0b already changed > that > > >>>>>to just msvcrt.dll. > > >>>>> > > >>>>>5i.3 - 7.7.1 have all dynamically linked msvcrt.dll, which has > been > > >>>>>an obligatory part of standard Windows installs for over a > decade > > > >>>>><http://en.wikipedia.org/wiki/Microsoft_Windows_library_files#Msv > > cr > > >>>>>t > > >>>>>.dll > > >>>>> > > >>>>> > > >>>>>> (Windows 2000 on), in Windows\system32 (and before that part > of a > > >>>>>> > > >>>>>> > > >>>>>normal Windows install since at least Windows 95 > > >>>>><http://support.microsoft.com/kb/895959> ). > > >>>>> > > >>>>> > > >>>>>There's a big difference > > >>>>><http://msdn.microsoft.com/en- > > >>>>> > > >>>>> > > >>us/library/abx4dbyh(VS.71).aspx#CodeSp > > >> > > >> > > >>>>>ippe > > >>>>>t0> between msvcrt.dll (a system file) and msvcr[71-100].dll. > The > > >>>>>former is guaranteed to be found (although you have no control > over > > >>>>>the exact version), the latter must be installed with your > application. > > >>>>> > > >>>>> > > >>>>>In theory you shouldn't rely on the system msvcrt.dll, since it > > >>>>>will be a different version from what you used in your own > testing, > > >>>>>but in practice for VW this seems to have worked well. I imagine > > >>>>>VW's reliance is pretty generic and stable, so it's been more > > >>>>>likely that things improved when MS shipped an update to > > >>>>>msvcrt.dll, than that things would break. XP SP2 was the > exception, > > >>>>>as the significant changes it introduced caused problems in many > > >>>>>applications. It looks like Microsoft are moving away from > allowing > > >>>>>3rd party apps to dynamically link to the system msvcrt.dll, so > > >>>>>Cincom should stop too. There's a good discussion > > >>>>><http://stackoverflow.com/questions/1073509/should-i- > redistribute- > > m > > >>>>>s > > >>>>>vcrt > > >>>>>-dll-with-my-application> on the pros and cons on StackOverflow. > > >>>>> > > >>>>> > > >>>>>So, with the exception of 3.0 (which was corrected in 3.0b), no > > >>>>>previous VM has dynamically depended on a particular > > >>>>>msvcr[40-100].dll. Those particular DLLs aren't shipped with > > >>>>>Windows, and if you depend on them you MUST ship them. > > >>>>> > > >>>>> > > >>>>>Better though would be to statically link the CRT for the 64-bit > > >>>>>VM, using /MT. That would also seem to be good advice for the > > >>>>>32-bit VM, to remove the dependency on the system msvcrt.dll. > > >>>>>Statically linking the 64-bit VM will also significantly reduce > the > > >>>>>total size of the application, since I imagine VW only uses a > tiny > > >>>>>fraction of the whole msvcrt100.dll. > > >>>>> > > >>>>> > > >>>>>Cheers, > > >>>>> > > >>>>>Steve > > >>>>> > > >>>>> > > >>>>> > > >>>>>From: [hidden email] [mailto:vw-dev- > > >>>>> > > >>>>> > > >>[hidden email]] > > >> > > >> > > >>>>>On Behalf Of Alan Knight > > >>>>>Sent: 11. helmikuuta 2011 1:34 > > >>>>>To: [hidden email] > > >>>>>Subject: Re: vw7.8 64-bit on windows error > > >>>>> > > >>>>> > > >>>>>I don't think we have statically linked the MSVCR libraries in > > >>>>>previous versions, at least not for a very long time. I also > don't > > >>>>>think that those libraries are part of the Windows installs, but > > >>>>>they tended to be there if you'd installed anything at all. And > > >>>>>possibly if the operating system included programs that were > built > > >>>>>with those compilers they would be for practical purposes > included. > > >>>>>The difference in this case is, I suspect, that people have > fewer > > >>>>>things installed that are 64-bit applications, and the compiler > is newer. > > >>>>> > > >>>>>It is not needed on 32-bit installations, because we are for the > > >>>>>moment still using an older compiler version for the 32-bit > > >>>>>versions, partly because of that dependency. Building the 64-bit > > >>>>>versions required the use of the more recent compiler. 32-bit > > >>>>>versions appear to my untrained eye to require MSVCRT.DLL with > no > > >>>>>version number embedded in the name. I don't believe it makes > any > > >>>>> > > >>>>> > > >>difference between visual.exe and vwnt.exe. > > >> > > >> > > >>>>>It's possible that we really ought to be installing it, but it > is > > >>>>>not something we've ever done in the past and it does not seem > to > > >>>>>have previously been an issue. > > >>>>> > > >>>>> > > >>>>> > > >>>>>In earlier versions, the necessary parts of the MSVCR library > have > > >>>>>been statically linked (IIRC), or then the relevant library has > > >>>>>been part of a normal Windows installation anyway (maybe in IE?). > > >>>>>Even the Cairo DLL was kindly made by Travis to be statically > > >>>>>linked rather than require > > >>>>>MSCVR90.dll: > > >>>>> > > >>>>>http://www.parcplace.net/list/vwnc-archive/0910/msg00085.html > > >>>>> > > >>>>>Information on static linking and msvcr100.dll is in the last > > >>>>>message > > >>>>>here: > > >>>>> > > >>>>> > > >>>>> > > >>>>> > > >>http://social.msdn.microsoft.com/Forums/en/vssetup/thread/6891665f- > f > > >> > > >> > > >>>>>d83- > > >>>>>426a-9d73-69d6d7e171a3 > > >>>>> > > >>>>> > > >>>>>As Martin said, a vendor using a redistributable dynamically > linked > > >>>>>library like this is expected to ship it as part of their > installer > > >>>>>- as can be seen from e.g. InstallShield, which comes with a > wide > > >>>>>range of redistributables that install builders can add to their > > >>>>>install. It's also what Microsoft says to do (IIUC): > > >>>>> > > >>>>>http://msdn.microsoft.com/en-us/library/ms235299.aspx > > >>>>> > > >>>>>"If you use a merge module that contains a Visual C++ DLL, you > must > > >>>>>include it in the Windows Installer package (or similar > > >>>>>installation > > >>>>>package) that you are using to deploy the application" > > >>>>> > > >>>>> > > >>>>>Of course, all this is just for what Cincom should do when > > >>>>>providing their product, if that product were just an > application. > > >>>>>Given the product in this case is a development environment, > Cincom > > >>>>>should also provide automation and/or instructions for > developers > > >>>>>to create and deploy their own products - including any > necessary > > >>>>> > > >>>>> > > >>redistributables. > > >> > > >> > > >>>>>Otherwise end users are going to be reporting that the > application > > >>>>>doesn't work, and developers aren't going to understand why (and > > >>>>>presumably Cincom isn't going to get any royalties in that > case!). > > >>>>> > > >>>>> > > >>>>>Is msvcr100.dll also needed on 32-bit VW 7.8 installations on > Windows? > > >>>>>Does it make a difference if we use the monolithic visual.exe VM > or > > >>>>>the split .exe+.dll VM? > > >>>>> > > >>>>> > > >>>>>Cheers, > > >>>>> > > >>>>>Steve > > >>>>> > > >>>>> > > >>>>> > > >>>>>________________________________ > > >>>>> > > >>>>>From: [hidden email] on behalf of Alan Knight > > >>>>>Sent: Thu 10/02/2011 19:55 > > >>>>>To: Martin McClure > > >>>>>Cc: [hidden email] > > >>>>>Subject: Re: vw7.8 64-bit on windows error > > >>>>> > > >>>>> > > >>>>>That isn't something we've done in the past. I think that > typically > > >>>>>those libraries end up installed quite widely as soon as you've > > >>>>>installed anything. And it would be a bit tricky, in that it > > >>>>>wouldn't be integrated with our installation mechanisms. I think > > >>>>>about the best we could do at this point would be to include a > copy > > >>>>>on the CD or download and people would have to install it > > >>>>>themselves. We can also look into trying to do something in the > > >>>>>next release when we expect to have Win64 as fully supported, > but > > >>>>>it's quite > > >>>>> > > >>>>> > > >>late to try much for this one. > > >> > > >> > > >>>>>On 2011-02-10 12:09 AM, Martin McClure wrote: > > >>>>> > > >>>>> > > >>>>>>On 02/09/11 11:11, Alan Knight wrote: > > >>>>>> > > >>>>>> > > >>>>>>>you need to install the appropriate MS runtime for the most > > >>>>>>>recent compiler. > > >>>>>>> > > >>>>>>> > > >>>>>>I'd gotten the impression that Microsoft's intent is that when > an > > >>>>>>application requires a particular version of the MSVCR library, > > >>>>>>the application vendor should ship that MSVCR library along > with > > >>>>>>the application. > > >>>>>> > > >>>>>>Would it be possible to include that with the Windows install? > > >>>>>> > > >>>>>>Regards, > > >>>>>> > > >>>>>>-Martin > > >>>>>> > > >>>>>> > > >>>>>-- > > >>>>>Alan Knight [|], Engineering Manager, Cincom Smalltalk > > >>>>>[hidden email] [hidden email] > > http://www.cincomsmalltalk.com > > >>>>><http://www.cincomsmalltalk.com/> > > >>>>> > > >>>>> > > >>>>> > > >>>>> > > >>>>> > > >>>>> > > >>_______________________________________________ > > >>vwnc mailing list > > >>[hidden email] > > >>http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > > >> > > >> > > >> > > > > > > > > >_______________________________________________ > > >vwnc mailing list > > >[hidden email] > > >http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > vwnc mailing list > [hidden email] > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: [now vw7.9] msvcr100.dll Re: vw7.8 64-bit onwindows error
|
|
In reply to this post by Boris Popov, DeepCove Labs (SNN)
Boris
What are the compatibility problems with TLS/SSL? Terry =========================================================== Terry Raymond Crafted Smalltalk 80 Lazywood Ln. Tiverton, RI 02878 (401) 624-4517 [hidden email] =========================================================== > -----Original Message----- > From: [hidden email] [mailto:[hidden email]] On > Behalf Of Boris Popov, DeepCove Labs > Sent: Sunday, July 15, 2012 9:51 PM > To: Carl Gundel > Cc: VWNC List > Subject: Re: [vwnc] [now vw7.9] msvcr100.dll Re: vw7.8 64-bit onwindows > error > > Don't worry, you're not the only one stuck on 7.8(.1); for us the issues with > TLS/SSL compatibility make the move impossible at this point. Let's see what > 7.10 brings us. > > -Boris > > On 2012-07-15, at 20:32, "Carl Gundel" <[hidden email]> wrote: > > > Niall, > > > > Thanks for the clarification. So if the question is "is it okay that msvcr100.dll > needs to distributed with VisualWorks?" > > > > For me the answer would have to be no. Telling my customers that they > now need to include this DLL represents a broken promise. > > > > It is not possible to statically link the needed functions because these > functions may become broken? Or is it possible but inconvenient? But the > msvcr100.dll may also become broken? > > > > I'm not sure why Microsoft doesn't simply provide this DLL and keep it up > to date using Windows Update. > > > > So I'll be stuck with VW7.8 until it no longer works. I hope that will be a very > long time coming. > > > > -Carl Gundel > > Liberty BASIC for Windows - http://www.libertybasic.com Run BASIC, > > easy web programming - http://www.runbasic.com > > > > On Jul 15, 2012, at 5:21 PM, Niall Ross <[hidden email]> wrote: > > > >> Dear Carl, Christian, David et al, > >> the msvcr100.dll does not have to be installed in a system location. > >> > >> For example, the 7.9 VW installer puts it in the system location if it can > write to that location. If it cannot, it puts dll in VW's bin/win (and 64bit in > bin/win64). Similarly, any app installer can put the dll in the same location as > their VM or single file .exe. > >> > >> A local msvcr100.dll acts > >> > >> - as the one used by our VM if no system one is installed on that > >> platform > >> > >> - as a softlink to the system one if present: our VM always uses > >> the system one if present > >> > >> As of VS2010, Microsoft no longer include the dll in its base > >> platforms. This is the change we are responding to - the > >> corresponding prior versions have always been there by default so we > >> never had to install them. (Actually, the dll is there,but hidden, > >> only for MS internal stuff and not promised to remain compatible.) > >> Thus the VS2010 and later dll has to be either > >> - installed in system > >> or > >> - installed locally > >> or > >> - statically linked > >> > >> So the corresponding single-file .exe options are: > >> > >> a) "the full install dance" - almost certainly what you don't want to > >> do if you're using the single file option > >> > >> b) Have your zip expand to YourApp.exe and msvcr100.dll, not just > >> YourApp.exe. As noted, if your customer later installs or upgrade a > >> system msvcr100.dll, it will all still work. (If you want, you can > >> have your installation notes tell the user: "If you can put our > >> msvcr100.dll in the bin and the .exe still works, leave it in the bin > >> - you don't need it." This merely saves them ~750K of space; no > >> other point.) > >> > >> c) Statically-link the dll to the VM: the difference from (b) is that if the > user upgrades their platform, you will not upgrade with it, so we're not > starting by encouraging this option. We're hoping our customers will say that > (b) is OK. > >> > >> (The relevant Microsoft team promise future backward compatibility of > >> the dll in all cases but discovery of major security hole.) > >> > >> HTH > >> Niall Ross > >> > >> > >>> Yes, this is going to be a show-stopper for using VW 7.9 for me as > >>> well :-( > >>> > >>> But since linking the DLLs statically to the VMs for Windows needs to be > done only once, maybe somebody did this and could share the VM with the > community? > >>> > >>> I wonder why Cincom is not able to provide such a VM... Is it so hard to > do or are there legal issues involved? > >>> > >>> I really hope that there will be a practical solution to this problem > without having to dive into C land to figure out how to do that myself... > >>> > >>> Christian > >>> > >>> > >>>> -----Ursprüngliche Nachricht----- > >>>> Von: [hidden email] [mailto:[hidden email]] > Im > >>>> Auftrag von Carl Gundel > >>>> Gesendet: Sonntag, 15. Juli 2012 06:31 > >>>> An: VWNC List > >>>> Betreff: [vwnc] [now vw7.9] msvcr100.dll Re: vw7.8 64-bit on > >>>> windows error > >>>> > >>>>> From the 7.9 release notes: > >>>> > >>>> "Windows OE DLL Requirement > >>>> Due to a compiler upgrade, the Windows VMs require that > >>>> msvcr100.dll be installed in its proper location (System32 or > >>>> SysWOW64).If this DLL is not already installed, the installer > >>>> installs and runs a program (VisualWorks32bitDLLPrereqs, and > >>>> VisualWorks64bitDLLPrereqs on 64-bit > >>>> systems) that installs the DLL(s) and registers VisualWorks' interest in > them. > >>>> After installation, an information screen tells you this has been > >>>> done. If you uninstall this program, VisualWorks is deregistered > >>>> for it, and the DLL is removed if no other program has an interest. > >>>> When deploying an application with the VM, you are responsible for > >>>> ensuring that this file is present on the target system." > >>>> > >>>> So, this is now required for 32-bit VisualWorks on Windows also? > >>>> > >>>> This is going to be very, very inconvenient for me. The single > >>>> file VM and the ability to embed the image in the VM are one of the > >>>> reasons I chose VisualWorks. Up to this point I have not needed > >>>> any extra libraries and this is very important to me and to my > >>>> customers. The msvcr100.dll throws a real monkey wrench into > >>>> things for me. I hope that Cincom will decide to statically link > >>>> whatever functions it needs from this DLL going forward. I may be > forced to stick with 7.8 otherwise. > >>>> > >>>> -Carl Gundel > >>>> http://www.libertybasic.com > >>>> http://www.runbasic.com > >>>> > >>>> On Sun, Feb 20, 2011 at 10:29 AM, Alan Knight <[hidden email]> > wrote: > >>>> > >>>>> Yes, this is expected. We'll need to do something about that, but > >>>>> for 7.8, where win64 is in preview, I think it's likely to remain > >>>>> and we'll sort out the various possibilities with a bit more time to > consider. > >>>>> > >>>>> > >>>>> On 11-02-20 6:36 AM, Steffen Märcker wrote: > >>>>> > >>>>>> I've just attempted to start the win64 vm on Windows 7 Prof. 64 > >>>>>> Bit and got the message to install msvcr100.dll too. Do I > >>>>>> understand this thread right that this is actually expected? > >>>>>> > >>>>>> Regards, Steffen > >>>>>> > >>>>>> > >>>>>> Am 11.02.2011, 11:17 Uhr, schrieb Steven Kelly > <[hidden email]>: > >>>>>> > >>>>>> > >>>>>>> I just went through all VW monolithic VMs from 2.0 to 7.7.1 with > >>>>>>> Dependency Walker: > >>>>>>> > >>>>>>> 2.0 and 2.5 statically linked any functions they called from > >>>>>>> msvcrt.dll > >>>>>>> > >>>>>>> 3.0 dynamically linked msvcrt40.dll, but 3.0b already changed > >>>>>>> that to just msvcrt.dll. > >>>>>>> > >>>>>>> 5i.3 - 7.7.1 have all dynamically linked msvcrt.dll, which has > >>>>>>> been an obligatory part of standard Windows installs for over a > >>>>>>> decade > >>>>>>> > <http://en.wikipedia.org/wiki/Microsoft_Windows_library_files#Ms > >>>>>>> vcrt > >>>>>>> .dll > >>>>>>> > >>>>>>>> (Windows 2000 on), in Windows\system32 (and before that part > of > >>>>>>>> a > >>>>>>>> > >>>>>>> normal Windows install since at least Windows 95 > >>>>>>> <http://support.microsoft.com/kb/895959> ). > >>>>>>> > >>>>>>> > >>>>>>> There's a big difference > >>>>>>> <http://msdn.microsoft.com/en- > >>>>>>> > >>>> us/library/abx4dbyh(VS.71).aspx#CodeSp > >>>> > >>>>>>> ippe > >>>>>>> t0> between msvcrt.dll (a system file) and msvcr[71-100].dll. > >>>>>>> t0> The > >>>>>>> former is guaranteed to be found (although you have no control > >>>>>>> over the exact version), the latter must be installed with your > application. > >>>>>>> > >>>>>>> > >>>>>>> In theory you shouldn't rely on the system msvcrt.dll, since it > >>>>>>> will be a different version from what you used in your own > >>>>>>> testing, but in practice for VW this seems to have worked well. > >>>>>>> I imagine VW's reliance is pretty generic and stable, so it's > >>>>>>> been more likely that things improved when MS shipped an update > >>>>>>> to msvcrt.dll, than that things would break. XP SP2 was the > >>>>>>> exception, as the significant changes it introduced caused > >>>>>>> problems in many applications. It looks like Microsoft are > >>>>>>> moving away from allowing 3rd party apps to dynamically link to > >>>>>>> the system msvcrt.dll, so Cincom should stop too. There's a good > >>>>>>> discussion > >>>>>>> <http://stackoverflow.com/questions/1073509/should-i-redistribut > >>>>>>> e-ms > >>>>>>> vcrt > >>>>>>> -dll-with-my-application> on the pros and cons on StackOverflow. > >>>>>>> > >>>>>>> > >>>>>>> So, with the exception of 3.0 (which was corrected in 3.0b), no > >>>>>>> previous VM has dynamically depended on a particular > >>>>>>> msvcr[40-100].dll. Those particular DLLs aren't shipped with > >>>>>>> Windows, and if you depend on them you MUST ship them. > >>>>>>> > >>>>>>> > >>>>>>> Better though would be to statically link the CRT for the 64-bit > >>>>>>> VM, using /MT. That would also seem to be good advice for the > >>>>>>> 32-bit VM, to remove the dependency on the system msvcrt.dll. > >>>>>>> Statically linking the 64-bit VM will also significantly reduce > >>>>>>> the total size of the application, since I imagine VW only uses > >>>>>>> a tiny fraction of the whole msvcrt100.dll. > >>>>>>> > >>>>>>> > >>>>>>> Cheers, > >>>>>>> > >>>>>>> Steve > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> From: [hidden email] [mailto:vw-dev- > >>>>>>> > >>>> [hidden email]] > >>>> > >>>>>>> On Behalf Of Alan Knight > >>>>>>> Sent: 11. helmikuuta 2011 1:34 > >>>>>>> To: [hidden email] > >>>>>>> Subject: Re: vw7.8 64-bit on windows error > >>>>>>> > >>>>>>> > >>>>>>> I don't think we have statically linked the MSVCR libraries in > >>>>>>> previous versions, at least not for a very long time. I also > >>>>>>> don't think that those libraries are part of the Windows > >>>>>>> installs, but they tended to be there if you'd installed > >>>>>>> anything at all. And possibly if the operating system included > >>>>>>> programs that were built with those compilers they would be for > practical purposes included. > >>>>>>> The difference in this case is, I suspect, that people have > >>>>>>> fewer things installed that are 64-bit applications, and the compiler > is newer. > >>>>>>> > >>>>>>> It is not needed on 32-bit installations, because we are for the > >>>>>>> moment still using an older compiler version for the 32-bit > >>>>>>> versions, partly because of that dependency. Building the 64-bit > >>>>>>> versions required the use of the more recent compiler. 32-bit > >>>>>>> versions appear to my untrained eye to require MSVCRT.DLL with > >>>>>>> no version number embedded in the name. I don't believe it makes > >>>>>>> any > >>>>>>> > >>>> difference between visual.exe and vwnt.exe. > >>>> > >>>>>>> It's possible that we really ought to be installing it, but it > >>>>>>> is not something we've ever done in the past and it does not > >>>>>>> seem to have previously been an issue. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> In earlier versions, the necessary parts of the MSVCR library > >>>>>>> have been statically linked (IIRC), or then the relevant library > >>>>>>> has been part of a normal Windows installation anyway (maybe in > >>>>>>> IE?). Even the Cairo DLL was kindly made by Travis to be > >>>>>>> statically linked rather than require > >>>>>>> MSCVR90.dll: > >>>>>>> > >>>>>>> http://www.parcplace.net/list/vwnc-archive/0910/msg00085.html > >>>>>>> > >>>>>>> Information on static linking and msvcr100.dll is in the last > >>>>>>> message > >>>>>>> here: > >>>>>>> > >>>>>>> > >>>>>>> > >>>> > http://social.msdn.microsoft.com/Forums/en/vssetup/thread/6891665f- > >>>> f > >>>> > >>>>>>> d83- > >>>>>>> 426a-9d73-69d6d7e171a3 > >>>>>>> > >>>>>>> > >>>>>>> As Martin said, a vendor using a redistributable dynamically > >>>>>>> linked library like this is expected to ship it as part of their > >>>>>>> installer > >>>>>>> - as can be seen from e.g. InstallShield, which comes with a > >>>>>>> wide range of redistributables that install builders can add to > >>>>>>> their install. It's also what Microsoft says to do (IIUC): > >>>>>>> > >>>>>>> http://msdn.microsoft.com/en-us/library/ms235299.aspx > >>>>>>> > >>>>>>> "If you use a merge module that contains a Visual C++ DLL, you > >>>>>>> must include it in the Windows Installer package (or similar > >>>>>>> installation > >>>>>>> package) that you are using to deploy the application" > >>>>>>> > >>>>>>> > >>>>>>> Of course, all this is just for what Cincom should do when > >>>>>>> providing their product, if that product were just an > >>>>>>> application. Given the product in this case is a development > >>>>>>> environment, Cincom should also provide automation and/or > >>>>>>> instructions for developers to create and deploy their own > >>>>>>> products - including any necessary > >>>>>>> > >>>> redistributables. > >>>> > >>>>>>> Otherwise end users are going to be reporting that the > >>>>>>> application doesn't work, and developers aren't going to > >>>>>>> understand why (and presumably Cincom isn't going to get any > royalties in that case!). > >>>>>>> > >>>>>>> > >>>>>>> Is msvcr100.dll also needed on 32-bit VW 7.8 installations on > Windows? > >>>>>>> Does it make a difference if we use the monolithic visual.exe VM > >>>>>>> or the split .exe+.dll VM? > >>>>>>> > >>>>>>> > >>>>>>> Cheers, > >>>>>>> > >>>>>>> Steve > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> ________________________________ > >>>>>>> > >>>>>>> From: [hidden email] on behalf of Alan Knight > >>>>>>> Sent: Thu 10/02/2011 19:55 > >>>>>>> To: Martin McClure > >>>>>>> Cc: [hidden email] > >>>>>>> Subject: Re: vw7.8 64-bit on windows error > >>>>>>> > >>>>>>> > >>>>>>> That isn't something we've done in the past. I think that > >>>>>>> typically those libraries end up installed quite widely as soon > >>>>>>> as you've installed anything. And it would be a bit tricky, in > >>>>>>> that it wouldn't be integrated with our installation mechanisms. > >>>>>>> I think about the best we could do at this point would be to > >>>>>>> include a copy on the CD or download and people would have to > >>>>>>> install it themselves. We can also look into trying to do > >>>>>>> something in the next release when we expect to have Win64 as > >>>>>>> fully supported, but it's quite > >>>>>>> > >>>> late to try much for this one. > >>>> > >>>>>>> On 2011-02-10 12:09 AM, Martin McClure wrote: > >>>>>>> > >>>>>>>> On 02/09/11 11:11, Alan Knight wrote: > >>>>>>>> > >>>>>>>>> you need to install the appropriate MS runtime for the most > >>>>>>>>> recent compiler. > >>>>>>>>> > >>>>>>>> I'd gotten the impression that Microsoft's intent is that when > >>>>>>>> an application requires a particular version of the MSVCR > >>>>>>>> library, the application vendor should ship that MSVCR library > >>>>>>>> along with the application. > >>>>>>>> > >>>>>>>> Would it be possible to include that with the Windows install? > >>>>>>>> > >>>>>>>> Regards, > >>>>>>>> > >>>>>>>> -Martin > >>>>>>>> > >>>>>>> -- > >>>>>>> Alan Knight [|], Engineering Manager, Cincom Smalltalk > >>>>>>> [hidden email] [hidden email] > http://www.cincomsmalltalk.com > >>>>>>> <http://www.cincomsmalltalk.com/> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>> _______________________________________________ > >>>> vwnc mailing list > >>>> [hidden email] > >>>> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > >>>> > >>>> > >>> > >>> > >>> _______________________________________________ > >>> vwnc mailing list > >>> [hidden email] > >>> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > >>> > >>> > >>> > >> > >> > > > > _______________________________________________ > > vwnc mailing list > > [hidden email] > > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > > _______________________________________________ > vwnc mailing list > [hidden email] > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: [now vw7.9] msvcr100.dll Re: vw7.8 64-bit onwindows error
|
|
Terry,
With the move to TLS, the framework is no longer able to connect to a subset of SSL endpoints. It's a messy issue that OpenSSL and web browsers tend to deal with by detecting various breakages and renegotiating or simply ignoring some inconsistencies in the server implementations. See a thread titled "[apr12.3] Xtreams.Incomplete" in vw-dev and the likes of http://www.imperialviolet.org/2011/02/04/oppractices.html and http://www.imperialviolet.org/2012/06/08/tlsversions.html for more information. I do believe Martin has a high priority AR to address this, there's just only so much they could do before 7.9's release. HTH, -Boris -----Original Message----- From: Terry Raymond [mailto:[hidden email]] Sent: Monday, July 16, 2012 8:15 AM To: Boris Popov, DeepCove Labs Cc: 'VWNC List' Subject: RE: [vwnc] [now vw7.9] msvcr100.dll Re: vw7.8 64-bit onwindows error Boris What are the compatibility problems with TLS/SSL? Terry =========================================================== Terry Raymond Crafted Smalltalk 80 Lazywood Ln. Tiverton, RI 02878 (401) 624-4517 [hidden email] =========================================================== > -----Original Message----- > From: [hidden email] [mailto:[hidden email]] On > Behalf Of Boris Popov, DeepCove Labs > Sent: Sunday, July 15, 2012 9:51 PM > To: Carl Gundel > Cc: VWNC List > Subject: Re: [vwnc] [now vw7.9] msvcr100.dll Re: vw7.8 64-bit > onwindows error > > Don't worry, you're not the only one stuck on 7.8(.1); for us the > issues with TLS/SSL compatibility make the move impossible at this > point. Let's see what > 7.10 brings us. > > -Boris > > On 2012-07-15, at 20:32, "Carl Gundel" <[hidden email]> wrote: > > > Niall, > > > > Thanks for the clarification. So if the question is "is it okay > > that msvcr100.dll > needs to distributed with VisualWorks?" > > > > For me the answer would have to be no. Telling my customers that > > they > now need to include this DLL represents a broken promise. > > > > It is not possible to statically link the needed functions because > > these > functions may become broken? Or is it possible but inconvenient? But > the msvcr100.dll may also become broken? > > > > I'm not sure why Microsoft doesn't simply provide this DLL and keep > > it up > to date using Windows Update. > > > > So I'll be stuck with VW7.8 until it no longer works. I hope that > > will be a very > long time coming. > > > > -Carl Gundel > > Liberty BASIC for Windows - http://www.libertybasic.com Run BASIC, > > easy web programming - http://www.runbasic.com > > > > On Jul 15, 2012, at 5:21 PM, Niall Ross <[hidden email]> wrote: > > > >> Dear Carl, Christian, David et al, > >> the msvcr100.dll does not have to be installed in a system location. > >> > >> For example, the 7.9 VW installer puts it in the system location if > >> it can > write to that location. If it cannot, it puts dll in VW's bin/win > (and 64bit in bin/win64). Similarly, any app installer can put the > dll in the same location as their VM or single file .exe. > >> > >> A local msvcr100.dll acts > >> > >> - as the one used by our VM if no system one is installed on that > >> platform > >> > >> - as a softlink to the system one if present: our VM always uses > >> the system one if present > >> > >> As of VS2010, Microsoft no longer include the dll in its base > >> platforms. This is the change we are responding to - the > >> corresponding prior versions have always been there by default so > >> we never had to install them. (Actually, the dll is there,but > >> hidden, only for MS internal stuff and not promised to remain > >> compatible.) Thus the VS2010 and later dll has to be either > >> - installed in system > >> or > >> - installed locally > >> or > >> - statically linked > >> > >> So the corresponding single-file .exe options are: > >> > >> a) "the full install dance" - almost certainly what you don't want > >> to do if you're using the single file option > >> > >> b) Have your zip expand to YourApp.exe and msvcr100.dll, not just > >> YourApp.exe. As noted, if your customer later installs or upgrade > >> a system msvcr100.dll, it will all still work. (If you want, you > >> can have your installation notes tell the user: "If you can put > >> our msvcr100.dll in the bin and the .exe still works, leave it in > >> the bin > >> - you don't need it." This merely saves them ~750K of space; no > >> other point.) > >> > >> c) Statically-link the dll to the VM: the difference from (b) is > >> that if the > user upgrades their platform, you will not upgrade with it, so we're > not starting by encouraging this option. We're hoping our customers > will say that > (b) is OK. > >> > >> (The relevant Microsoft team promise future backward compatibility > >> of the dll in all cases but discovery of major security hole.) > >> > >> HTH > >> Niall Ross > >> > >> > >>> Yes, this is going to be a show-stopper for using VW 7.9 for me as > >>> well :-( > >>> > >>> But since linking the DLLs statically to the VMs for Windows needs > >>> to be > done only once, maybe somebody did this and could share the VM with > the community? > >>> > >>> I wonder why Cincom is not able to provide such a VM... Is it so > >>> hard to > do or are there legal issues involved? > >>> > >>> I really hope that there will be a practical solution to this > >>> problem > without having to dive into C land to figure out how to do that myself... > >>> > >>> Christian > >>> > >>> > >>>> -----Ursprüngliche Nachricht----- > >>>> Von: [hidden email] [mailto:[hidden email]] > Im > >>>> Auftrag von Carl Gundel > >>>> Gesendet: Sonntag, 15. Juli 2012 06:31 > >>>> An: VWNC List > >>>> Betreff: [vwnc] [now vw7.9] msvcr100.dll Re: vw7.8 64-bit on > >>>> windows error > >>>> > >>>>> From the 7.9 release notes: > >>>> > >>>> "Windows OE DLL Requirement > >>>> Due to a compiler upgrade, the Windows VMs require that > >>>> msvcr100.dll be installed in its proper location (System32 or > >>>> SysWOW64).If this DLL is not already installed, the installer > >>>> installs and runs a program (VisualWorks32bitDLLPrereqs, and > >>>> VisualWorks64bitDLLPrereqs on 64-bit > >>>> systems) that installs the DLL(s) and registers VisualWorks' > >>>> interest in > them. > >>>> After installation, an information screen tells you this has been > >>>> done. If you uninstall this program, VisualWorks is deregistered > >>>> for it, and the DLL is removed if no other program has an interest. > >>>> When deploying an application with the VM, you are responsible > >>>> for ensuring that this file is present on the target system." > >>>> > >>>> So, this is now required for 32-bit VisualWorks on Windows also? > >>>> > >>>> This is going to be very, very inconvenient for me. The single > >>>> file VM and the ability to embed the image in the VM are one of > >>>> the reasons I chose VisualWorks. Up to this point I have not > >>>> needed any extra libraries and this is very important to me and > >>>> to my customers. The msvcr100.dll throws a real monkey wrench > >>>> into things for me. I hope that Cincom will decide to statically > >>>> link whatever functions it needs from this DLL going forward. I > >>>> may be > forced to stick with 7.8 otherwise. > >>>> > >>>> -Carl Gundel > >>>> http://www.libertybasic.com > >>>> http://www.runbasic.com > >>>> > >>>> On Sun, Feb 20, 2011 at 10:29 AM, Alan Knight <[hidden email]> > wrote: > >>>> > >>>>> Yes, this is expected. We'll need to do something about that, > >>>>> but for 7.8, where win64 is in preview, I think it's likely to > >>>>> remain and we'll sort out the various possibilities with a bit > >>>>> more time to > consider. > >>>>> > >>>>> > >>>>> On 11-02-20 6:36 AM, Steffen Märcker wrote: > >>>>> > >>>>>> I've just attempted to start the win64 vm on Windows 7 Prof. 64 > >>>>>> Bit and got the message to install msvcr100.dll too. Do I > >>>>>> understand this thread right that this is actually expected? > >>>>>> > >>>>>> Regards, Steffen > >>>>>> > >>>>>> > >>>>>> Am 11.02.2011, 11:17 Uhr, schrieb Steven Kelly > <[hidden email]>: > >>>>>> > >>>>>> > >>>>>>> I just went through all VW monolithic VMs from 2.0 to 7.7.1 > >>>>>>> with Dependency Walker: > >>>>>>> > >>>>>>> 2.0 and 2.5 statically linked any functions they called from > >>>>>>> msvcrt.dll > >>>>>>> > >>>>>>> 3.0 dynamically linked msvcrt40.dll, but 3.0b already changed > >>>>>>> that to just msvcrt.dll. > >>>>>>> > >>>>>>> 5i.3 - 7.7.1 have all dynamically linked msvcrt.dll, which has > >>>>>>> been an obligatory part of standard Windows installs for over > >>>>>>> a decade > >>>>>>> > <http://en.wikipedia.org/wiki/Microsoft_Windows_library_files#Ms > >>>>>>> vcrt > >>>>>>> .dll > >>>>>>> > >>>>>>>> (Windows 2000 on), in Windows\system32 (and before that part > of > >>>>>>>> a > >>>>>>>> > >>>>>>> normal Windows install since at least Windows 95 > >>>>>>> <http://support.microsoft.com/kb/895959> ). > >>>>>>> > >>>>>>> > >>>>>>> There's a big difference > >>>>>>> <http://msdn.microsoft.com/en- > >>>>>>> > >>>> us/library/abx4dbyh(VS.71).aspx#CodeSp > >>>> > >>>>>>> ippe > >>>>>>> t0> between msvcrt.dll (a system file) and msvcr[71-100].dll. > >>>>>>> t0> The > >>>>>>> former is guaranteed to be found (although you have no control > >>>>>>> over the exact version), the latter must be installed with > >>>>>>> your > application. > >>>>>>> > >>>>>>> > >>>>>>> In theory you shouldn't rely on the system msvcrt.dll, since > >>>>>>> it will be a different version from what you used in your own > >>>>>>> testing, but in practice for VW this seems to have worked well. > >>>>>>> I imagine VW's reliance is pretty generic and stable, so it's > >>>>>>> been more likely that things improved when MS shipped an > >>>>>>> update to msvcrt.dll, than that things would break. XP SP2 was > >>>>>>> the exception, as the significant changes it introduced caused > >>>>>>> problems in many applications. It looks like Microsoft are > >>>>>>> moving away from allowing 3rd party apps to dynamically link > >>>>>>> to the system msvcrt.dll, so Cincom should stop too. There's a > >>>>>>> good discussion > >>>>>>> <http://stackoverflow.com/questions/1073509/should-i-redistrib > >>>>>>> ut > >>>>>>> e-ms > >>>>>>> vcrt > >>>>>>> -dll-with-my-application> on the pros and cons on StackOverflow. > >>>>>>> > >>>>>>> > >>>>>>> So, with the exception of 3.0 (which was corrected in 3.0b), > >>>>>>> no previous VM has dynamically depended on a particular > >>>>>>> msvcr[40-100].dll. Those particular DLLs aren't shipped with > >>>>>>> Windows, and if you depend on them you MUST ship them. > >>>>>>> > >>>>>>> > >>>>>>> Better though would be to statically link the CRT for the > >>>>>>> 64-bit VM, using /MT. That would also seem to be good advice > >>>>>>> for the 32-bit VM, to remove the dependency on the system msvcrt.dll. > >>>>>>> Statically linking the 64-bit VM will also significantly > >>>>>>> reduce the total size of the application, since I imagine VW > >>>>>>> only uses a tiny fraction of the whole msvcrt100.dll. > >>>>>>> > >>>>>>> > >>>>>>> Cheers, > >>>>>>> > >>>>>>> Steve > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> From: [hidden email] [mailto:vw-dev- > >>>>>>> > >>>> [hidden email]] > >>>> > >>>>>>> On Behalf Of Alan Knight > >>>>>>> Sent: 11. helmikuuta 2011 1:34 > >>>>>>> To: [hidden email] > >>>>>>> Subject: Re: vw7.8 64-bit on windows error > >>>>>>> > >>>>>>> > >>>>>>> I don't think we have statically linked the MSVCR libraries in > >>>>>>> previous versions, at least not for a very long time. I also > >>>>>>> don't think that those libraries are part of the Windows > >>>>>>> installs, but they tended to be there if you'd installed > >>>>>>> anything at all. And possibly if the operating system included > >>>>>>> programs that were built with those compilers they would be > >>>>>>> for > practical purposes included. > >>>>>>> The difference in this case is, I suspect, that people have > >>>>>>> fewer things installed that are 64-bit applications, and the > >>>>>>> compiler > is newer. > >>>>>>> > >>>>>>> It is not needed on 32-bit installations, because we are for > >>>>>>> the moment still using an older compiler version for the > >>>>>>> 32-bit versions, partly because of that dependency. Building > >>>>>>> the 64-bit versions required the use of the more recent > >>>>>>> compiler. 32-bit versions appear to my untrained eye to > >>>>>>> require MSVCRT.DLL with no version number embedded in the > >>>>>>> name. I don't believe it makes any > >>>>>>> > >>>> difference between visual.exe and vwnt.exe. > >>>> > >>>>>>> It's possible that we really ought to be installing it, but it > >>>>>>> is not something we've ever done in the past and it does not > >>>>>>> seem to have previously been an issue. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> In earlier versions, the necessary parts of the MSVCR library > >>>>>>> have been statically linked (IIRC), or then the relevant > >>>>>>> library has been part of a normal Windows installation anyway > >>>>>>> (maybe in IE?). Even the Cairo DLL was kindly made by Travis > >>>>>>> to be statically linked rather than require > >>>>>>> MSCVR90.dll: > >>>>>>> > >>>>>>> http://www.parcplace.net/list/vwnc-archive/0910/msg00085.html > >>>>>>> > >>>>>>> Information on static linking and msvcr100.dll is in the last > >>>>>>> message > >>>>>>> here: > >>>>>>> > >>>>>>> > >>>>>>> > >>>> > http://social.msdn.microsoft.com/Forums/en/vssetup/thread/6891665f- > >>>> f > >>>> > >>>>>>> d83- > >>>>>>> 426a-9d73-69d6d7e171a3 > >>>>>>> > >>>>>>> > >>>>>>> As Martin said, a vendor using a redistributable dynamically > >>>>>>> linked library like this is expected to ship it as part of > >>>>>>> their installer > >>>>>>> - as can be seen from e.g. InstallShield, which comes with a > >>>>>>> wide range of redistributables that install builders can add > >>>>>>> to their install. It's also what Microsoft says to do (IIUC): > >>>>>>> > >>>>>>> http://msdn.microsoft.com/en-us/library/ms235299.aspx > >>>>>>> > >>>>>>> "If you use a merge module that contains a Visual C++ DLL, you > >>>>>>> must include it in the Windows Installer package (or similar > >>>>>>> installation > >>>>>>> package) that you are using to deploy the application" > >>>>>>> > >>>>>>> > >>>>>>> Of course, all this is just for what Cincom should do when > >>>>>>> providing their product, if that product were just an > >>>>>>> application. Given the product in this case is a development > >>>>>>> environment, Cincom should also provide automation and/or > >>>>>>> instructions for developers to create and deploy their own > >>>>>>> products - including any necessary > >>>>>>> > >>>> redistributables. > >>>> > >>>>>>> Otherwise end users are going to be reporting that the > >>>>>>> application doesn't work, and developers aren't going to > >>>>>>> understand why (and presumably Cincom isn't going to get any > royalties in that case!). > >>>>>>> > >>>>>>> > >>>>>>> Is msvcr100.dll also needed on 32-bit VW 7.8 installations on > Windows? > >>>>>>> Does it make a difference if we use the monolithic visual.exe > >>>>>>> VM or the split .exe+.dll VM? > >>>>>>> > >>>>>>> > >>>>>>> Cheers, > >>>>>>> > >>>>>>> Steve > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> ________________________________ > >>>>>>> > >>>>>>> From: [hidden email] on behalf of Alan Knight > >>>>>>> Sent: Thu 10/02/2011 19:55 > >>>>>>> To: Martin McClure > >>>>>>> Cc: [hidden email] > >>>>>>> Subject: Re: vw7.8 64-bit on windows error > >>>>>>> > >>>>>>> > >>>>>>> That isn't something we've done in the past. I think that > >>>>>>> typically those libraries end up installed quite widely as > >>>>>>> soon as you've installed anything. And it would be a bit > >>>>>>> tricky, in that it wouldn't be integrated with our installation mechanisms. > >>>>>>> I think about the best we could do at this point would be to > >>>>>>> include a copy on the CD or download and people would have to > >>>>>>> install it themselves. We can also look into trying to do > >>>>>>> something in the next release when we expect to have Win64 as > >>>>>>> fully supported, but it's quite > >>>>>>> > >>>> late to try much for this one. > >>>> > >>>>>>> On 2011-02-10 12:09 AM, Martin McClure wrote: > >>>>>>> > >>>>>>>> On 02/09/11 11:11, Alan Knight wrote: > >>>>>>>> > >>>>>>>>> you need to install the appropriate MS runtime for the most > >>>>>>>>> recent compiler. > >>>>>>>>> > >>>>>>>> I'd gotten the impression that Microsoft's intent is that > >>>>>>>> when an application requires a particular version of the > >>>>>>>> MSVCR library, the application vendor should ship that MSVCR > >>>>>>>> library along with the application. > >>>>>>>> > >>>>>>>> Would it be possible to include that with the Windows install? > >>>>>>>> > >>>>>>>> Regards, > >>>>>>>> > >>>>>>>> -Martin > >>>>>>>> > >>>>>>> -- > >>>>>>> Alan Knight [|], Engineering Manager, Cincom Smalltalk > >>>>>>> [hidden email] [hidden email] > http://www.cincomsmalltalk.com > >>>>>>> <http://www.cincomsmalltalk.com/> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>> _______________________________________________ > >>>> vwnc mailing list > >>>> [hidden email] > >>>> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > >>>> > >>>> > >>> > >>> > >>> _______________________________________________ > >>> vwnc mailing list > >>> [hidden email] > >>> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > >>> > >>> > >>> > >> > >> > > > > _______________________________________________ > > vwnc mailing list > > [hidden email] > > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > > _______________________________________________ > vwnc mailing list > [hidden email] > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: [now vw7.9] msvcr100.dll Re: vw7.8 64-bit onwindows error
|
|
Boris
Did you try a partial upgrade, i.e. use a 7.9 base but use 7.8.1 Net parcels? Terry =========================================================== Terry Raymond Crafted Smalltalk 80 Lazywood Ln. Tiverton, RI 02878 (401) 624-4517 [hidden email] =========================================================== > -----Original Message----- > From: Boris Popov, DeepCove Labs [mailto:[hidden email]] > Sent: Monday, July 16, 2012 8:24 AM > To: Terry Raymond > Cc: VWNC List > Subject: RE: [vwnc] [now vw7.9] msvcr100.dll Re: vw7.8 64-bit onwindows > error > > Terry, > > With the move to TLS, the framework is no longer able to connect to a subset > of SSL endpoints. It's a messy issue that OpenSSL and web browsers tend to > deal with by detecting various breakages and renegotiating or simply ignoring > some inconsistencies in the server implementations. See a thread titled > "[apr12.3] Xtreams.Incomplete" in vw-dev and the likes of > http://www.imperialviolet.org/2011/02/04/oppractices.html and > http://www.imperialviolet.org/2012/06/08/tlsversions.html for more > information. I do believe Martin has a high priority AR to address this, there's > just only so much they could do before 7.9's release. > > HTH, > > -Boris > > -----Original Message----- > From: Terry Raymond [mailto:[hidden email]] > Sent: Monday, July 16, 2012 8:15 AM > To: Boris Popov, DeepCove Labs > Cc: 'VWNC List' > Subject: RE: [vwnc] [now vw7.9] msvcr100.dll Re: vw7.8 64-bit onwindows > error > > Boris > > What are the compatibility problems with TLS/SSL? > > Terry > > ========================================================== > = > Terry Raymond > Crafted Smalltalk > 80 Lazywood Ln. > Tiverton, RI 02878 > (401) 624-4517 [hidden email] > ========================================================== > = > > > -----Original Message----- > > From: [hidden email] [mailto:[hidden email]] On > > Behalf Of Boris Popov, DeepCove Labs > > Sent: Sunday, July 15, 2012 9:51 PM > > To: Carl Gundel > > Cc: VWNC List > > Subject: Re: [vwnc] [now vw7.9] msvcr100.dll Re: vw7.8 64-bit > > onwindows error > > > > Don't worry, you're not the only one stuck on 7.8(.1); for us the > > issues with TLS/SSL compatibility make the move impossible at this > > point. Let's see what > > 7.10 brings us. > > > > -Boris > > > > On 2012-07-15, at 20:32, "Carl Gundel" <[hidden email]> wrote: > > > > > Niall, > > > > > > Thanks for the clarification. So if the question is "is it okay > > > that msvcr100.dll > > needs to distributed with VisualWorks?" > > > > > > For me the answer would have to be no. Telling my customers that > > > they > > now need to include this DLL represents a broken promise. > > > > > > It is not possible to statically link the needed functions because > > > these > > functions may become broken? Or is it possible but inconvenient? But > > the msvcr100.dll may also become broken? > > > > > > I'm not sure why Microsoft doesn't simply provide this DLL and keep > > > it up > > to date using Windows Update. > > > > > > So I'll be stuck with VW7.8 until it no longer works. I hope that > > > will be a very > > long time coming. > > > > > > -Carl Gundel > > > Liberty BASIC for Windows - http://www.libertybasic.com Run BASIC, > > > easy web programming - http://www.runbasic.com > > > > > > On Jul 15, 2012, at 5:21 PM, Niall Ross <[hidden email]> wrote: > > > > > >> Dear Carl, Christian, David et al, > > >> the msvcr100.dll does not have to be installed in a system location. > > >> > > >> For example, the 7.9 VW installer puts it in the system location if > > >> it can > > write to that location. If it cannot, it puts dll in VW's bin/win > > (and 64bit in bin/win64). Similarly, any app installer can put the > > dll in the same location as their VM or single file .exe. > > >> > > >> A local msvcr100.dll acts > > >> > > >> - as the one used by our VM if no system one is installed on that > > >> platform > > >> > > >> - as a softlink to the system one if present: our VM always uses > > >> the system one if present > > >> > > >> As of VS2010, Microsoft no longer include the dll in its base > > >> platforms. This is the change we are responding to - the > > >> corresponding prior versions have always been there by default so > > >> we never had to install them. (Actually, the dll is there,but > > >> hidden, only for MS internal stuff and not promised to remain > > >> compatible.) Thus the VS2010 and later dll has to be either > > >> - installed in system > > >> or > > >> - installed locally > > >> or > > >> - statically linked > > >> > > >> So the corresponding single-file .exe options are: > > >> > > >> a) "the full install dance" - almost certainly what you don't want > > >> to do if you're using the single file option > > >> > > >> b) Have your zip expand to YourApp.exe and msvcr100.dll, not just > > >> YourApp.exe. As noted, if your customer later installs or upgrade > > >> a system msvcr100.dll, it will all still work. (If you want, you > > >> can have your installation notes tell the user: "If you can put > > >> our msvcr100.dll in the bin and the .exe still works, leave it in > > >> the bin > > >> - you don't need it." This merely saves them ~750K of space; no > > >> other point.) > > >> > > >> c) Statically-link the dll to the VM: the difference from (b) is > > >> that if the > > user upgrades their platform, you will not upgrade with it, so we're > > not starting by encouraging this option. We're hoping our customers > > will say that > > (b) is OK. > > >> > > >> (The relevant Microsoft team promise future backward compatibility > > >> of the dll in all cases but discovery of major security hole.) > > >> > > >> HTH > > >> Niall Ross > > >> > > >> > > >>> Yes, this is going to be a show-stopper for using VW 7.9 for me as > > >>> well :-( > > >>> > > >>> But since linking the DLLs statically to the VMs for Windows needs > > >>> to be > > done only once, maybe somebody did this and could share the VM with > > the community? > > >>> > > >>> I wonder why Cincom is not able to provide such a VM... Is it so > > >>> hard to > > do or are there legal issues involved? > > >>> > > >>> I really hope that there will be a practical solution to this > > >>> problem > > without having to dive into C land to figure out how to do that myself... > > >>> > > >>> Christian > > >>> > > >>> > > >>>> -----Ursprüngliche Nachricht----- > > >>>> Von: [hidden email] [mailto:vwnc- > [hidden email]] > > Im > > >>>> Auftrag von Carl Gundel > > >>>> Gesendet: Sonntag, 15. Juli 2012 06:31 > > >>>> An: VWNC List > > >>>> Betreff: [vwnc] [now vw7.9] msvcr100.dll Re: vw7.8 64-bit on > > >>>> windows error > > >>>> > > >>>>> From the 7.9 release notes: > > >>>> > > >>>> "Windows OE DLL Requirement > > >>>> Due to a compiler upgrade, the Windows VMs require that > > >>>> msvcr100.dll be installed in its proper location (System32 or > > >>>> SysWOW64).If this DLL is not already installed, the installer > > >>>> installs and runs a program (VisualWorks32bitDLLPrereqs, and > > >>>> VisualWorks64bitDLLPrereqs on 64-bit > > >>>> systems) that installs the DLL(s) and registers VisualWorks' > > >>>> interest in > > them. > > >>>> After installation, an information screen tells you this has been > > >>>> done. If you uninstall this program, VisualWorks is deregistered > > >>>> for it, and the DLL is removed if no other program has an interest. > > >>>> When deploying an application with the VM, you are responsible > > >>>> for ensuring that this file is present on the target system." > > >>>> > > >>>> So, this is now required for 32-bit VisualWorks on Windows also? > > >>>> > > >>>> This is going to be very, very inconvenient for me. The single > > >>>> file VM and the ability to embed the image in the VM are one of > > >>>> the reasons I chose VisualWorks. Up to this point I have not > > >>>> needed any extra libraries and this is very important to me and > > >>>> to my customers. The msvcr100.dll throws a real monkey wrench > > >>>> into things for me. I hope that Cincom will decide to statically > > >>>> link whatever functions it needs from this DLL going forward. I > > >>>> may be > > forced to stick with 7.8 otherwise. > > >>>> > > >>>> -Carl Gundel > > >>>> http://www.libertybasic.com > > >>>> http://www.runbasic.com > > >>>> > > >>>> On Sun, Feb 20, 2011 at 10:29 AM, Alan Knight <[hidden email]> > > wrote: > > >>>> > > >>>>> Yes, this is expected. We'll need to do something about that, > > >>>>> but for 7.8, where win64 is in preview, I think it's likely to > > >>>>> remain and we'll sort out the various possibilities with a bit > > >>>>> more time to > > consider. > > >>>>> > > >>>>> > > >>>>> On 11-02-20 6:36 AM, Steffen Märcker wrote: > > >>>>> > > >>>>>> I've just attempted to start the win64 vm on Windows 7 Prof. 64 > > >>>>>> Bit and got the message to install msvcr100.dll too. Do I > > >>>>>> understand this thread right that this is actually expected? > > >>>>>> > > >>>>>> Regards, Steffen > > >>>>>> > > >>>>>> > > >>>>>> Am 11.02.2011, 11:17 Uhr, schrieb Steven Kelly > > <[hidden email]>: > > >>>>>> > > >>>>>> > > >>>>>>> I just went through all VW monolithic VMs from 2.0 to 7.7.1 > > >>>>>>> with Dependency Walker: > > >>>>>>> > > >>>>>>> 2.0 and 2.5 statically linked any functions they called from > > >>>>>>> msvcrt.dll > > >>>>>>> > > >>>>>>> 3.0 dynamically linked msvcrt40.dll, but 3.0b already changed > > >>>>>>> that to just msvcrt.dll. > > >>>>>>> > > >>>>>>> 5i.3 - 7.7.1 have all dynamically linked msvcrt.dll, which has > > >>>>>>> been an obligatory part of standard Windows installs for over > > >>>>>>> a decade > > >>>>>>> > > <http://en.wikipedia.org/wiki/Microsoft_Windows_library_files#Ms > > >>>>>>> vcrt > > >>>>>>> .dll > > >>>>>>> > > >>>>>>>> (Windows 2000 on), in Windows\system32 (and before that part > > of > > >>>>>>>> a > > >>>>>>>> > > >>>>>>> normal Windows install since at least Windows 95 > > >>>>>>> <http://support.microsoft.com/kb/895959> ). > > >>>>>>> > > >>>>>>> > > >>>>>>> There's a big difference > > >>>>>>> <http://msdn.microsoft.com/en- > > >>>>>>> > > >>>> us/library/abx4dbyh(VS.71).aspx#CodeSp > > >>>> > > >>>>>>> ippe > > >>>>>>> t0> between msvcrt.dll (a system file) and msvcr[71-100].dll. > > >>>>>>> t0> The > > >>>>>>> former is guaranteed to be found (although you have no control > > >>>>>>> over the exact version), the latter must be installed with > > >>>>>>> your > > application. > > >>>>>>> > > >>>>>>> > > >>>>>>> In theory you shouldn't rely on the system msvcrt.dll, since > > >>>>>>> it will be a different version from what you used in your own > > >>>>>>> testing, but in practice for VW this seems to have worked well. > > >>>>>>> I imagine VW's reliance is pretty generic and stable, so it's > > >>>>>>> been more likely that things improved when MS shipped an > > >>>>>>> update to msvcrt.dll, than that things would break. XP SP2 was > > >>>>>>> the exception, as the significant changes it introduced caused > > >>>>>>> problems in many applications. It looks like Microsoft are > > >>>>>>> moving away from allowing 3rd party apps to dynamically link > > >>>>>>> to the system msvcrt.dll, so Cincom should stop too. There's a > > >>>>>>> good discussion > > >>>>>>> <http://stackoverflow.com/questions/1073509/should-i-redistrib > > >>>>>>> ut > > >>>>>>> e-ms > > >>>>>>> vcrt > > >>>>>>> -dll-with-my-application> on the pros and cons on > StackOverflow. > > >>>>>>> > > >>>>>>> > > >>>>>>> So, with the exception of 3.0 (which was corrected in 3.0b), > > >>>>>>> no previous VM has dynamically depended on a particular > > >>>>>>> msvcr[40-100].dll. Those particular DLLs aren't shipped with > > >>>>>>> Windows, and if you depend on them you MUST ship them. > > >>>>>>> > > >>>>>>> > > >>>>>>> Better though would be to statically link the CRT for the > > >>>>>>> 64-bit VM, using /MT. That would also seem to be good advice > > >>>>>>> for the 32-bit VM, to remove the dependency on the system > msvcrt.dll. > > >>>>>>> Statically linking the 64-bit VM will also significantly > > >>>>>>> reduce the total size of the application, since I imagine VW > > >>>>>>> only uses a tiny fraction of the whole msvcrt100.dll. > > >>>>>>> > > >>>>>>> > > >>>>>>> Cheers, > > >>>>>>> > > >>>>>>> Steve > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> From: [hidden email] [mailto:vw-dev- > > >>>>>>> > > >>>> [hidden email]] > > >>>> > > >>>>>>> On Behalf Of Alan Knight > > >>>>>>> Sent: 11. helmikuuta 2011 1:34 > > >>>>>>> To: [hidden email] > > >>>>>>> Subject: Re: vw7.8 64-bit on windows error > > >>>>>>> > > >>>>>>> > > >>>>>>> I don't think we have statically linked the MSVCR libraries in > > >>>>>>> previous versions, at least not for a very long time. I also > > >>>>>>> don't think that those libraries are part of the Windows > > >>>>>>> installs, but they tended to be there if you'd installed > > >>>>>>> anything at all. And possibly if the operating system included > > >>>>>>> programs that were built with those compilers they would be > > >>>>>>> for > > practical purposes included. > > >>>>>>> The difference in this case is, I suspect, that people have > > >>>>>>> fewer things installed that are 64-bit applications, and the > > >>>>>>> compiler > > is newer. > > >>>>>>> > > >>>>>>> It is not needed on 32-bit installations, because we are for > > >>>>>>> the moment still using an older compiler version for the > > >>>>>>> 32-bit versions, partly because of that dependency. Building > > >>>>>>> the 64-bit versions required the use of the more recent > > >>>>>>> compiler. 32-bit versions appear to my untrained eye to > > >>>>>>> require MSVCRT.DLL with no version number embedded in the > > >>>>>>> name. I don't believe it makes any > > >>>>>>> > > >>>> difference between visual.exe and vwnt.exe. > > >>>> > > >>>>>>> It's possible that we really ought to be installing it, but it > > >>>>>>> is not something we've ever done in the past and it does not > > >>>>>>> seem to have previously been an issue. > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> In earlier versions, the necessary parts of the MSVCR library > > >>>>>>> have been statically linked (IIRC), or then the relevant > > >>>>>>> library has been part of a normal Windows installation anyway > > >>>>>>> (maybe in IE?). Even the Cairo DLL was kindly made by Travis > > >>>>>>> to be statically linked rather than require > > >>>>>>> MSCVR90.dll: > > >>>>>>> > > >>>>>>> http://www.parcplace.net/list/vwnc- > archive/0910/msg00085.html > > >>>>>>> > > >>>>>>> Information on static linking and msvcr100.dll is in the last > > >>>>>>> message > > >>>>>>> here: > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>> > > http://social.msdn.microsoft.com/Forums/en/vssetup/thread/6891665f- > > >>>> f > > >>>> > > >>>>>>> d83- > > >>>>>>> 426a-9d73-69d6d7e171a3 > > >>>>>>> > > >>>>>>> > > >>>>>>> As Martin said, a vendor using a redistributable dynamically > > >>>>>>> linked library like this is expected to ship it as part of > > >>>>>>> their installer > > >>>>>>> - as can be seen from e.g. InstallShield, which comes with a > > >>>>>>> wide range of redistributables that install builders can add > > >>>>>>> to their install. It's also what Microsoft says to do (IIUC): > > >>>>>>> > > >>>>>>> http://msdn.microsoft.com/en-us/library/ms235299.aspx > > >>>>>>> > > >>>>>>> "If you use a merge module that contains a Visual C++ DLL, you > > >>>>>>> must include it in the Windows Installer package (or similar > > >>>>>>> installation > > >>>>>>> package) that you are using to deploy the application" > > >>>>>>> > > >>>>>>> > > >>>>>>> Of course, all this is just for what Cincom should do when > > >>>>>>> providing their product, if that product were just an > > >>>>>>> application. Given the product in this case is a development > > >>>>>>> environment, Cincom should also provide automation and/or > > >>>>>>> instructions for developers to create and deploy their own > > >>>>>>> products - including any necessary > > >>>>>>> > > >>>> redistributables. > > >>>> > > >>>>>>> Otherwise end users are going to be reporting that the > > >>>>>>> application doesn't work, and developers aren't going to > > >>>>>>> understand why (and presumably Cincom isn't going to get any > > royalties in that case!). > > >>>>>>> > > >>>>>>> > > >>>>>>> Is msvcr100.dll also needed on 32-bit VW 7.8 installations on > > Windows? > > >>>>>>> Does it make a difference if we use the monolithic visual.exe > > >>>>>>> VM or the split .exe+.dll VM? > > >>>>>>> > > >>>>>>> > > >>>>>>> Cheers, > > >>>>>>> > > >>>>>>> Steve > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> ________________________________ > > >>>>>>> > > >>>>>>> From: [hidden email] on behalf of Alan Knight > > >>>>>>> Sent: Thu 10/02/2011 19:55 > > >>>>>>> To: Martin McClure > > >>>>>>> Cc: [hidden email] > > >>>>>>> Subject: Re: vw7.8 64-bit on windows error > > >>>>>>> > > >>>>>>> > > >>>>>>> That isn't something we've done in the past. I think that > > >>>>>>> typically those libraries end up installed quite widely as > > >>>>>>> soon as you've installed anything. And it would be a bit > > >>>>>>> tricky, in that it wouldn't be integrated with our installation > mechanisms. > > >>>>>>> I think about the best we could do at this point would be to > > >>>>>>> include a copy on the CD or download and people would have to > > >>>>>>> install it themselves. We can also look into trying to do > > >>>>>>> something in the next release when we expect to have Win64 as > > >>>>>>> fully supported, but it's quite > > >>>>>>> > > >>>> late to try much for this one. > > >>>> > > >>>>>>> On 2011-02-10 12:09 AM, Martin McClure wrote: > > >>>>>>> > > >>>>>>>> On 02/09/11 11:11, Alan Knight wrote: > > >>>>>>>> > > >>>>>>>>> you need to install the appropriate MS runtime for the most > > >>>>>>>>> recent compiler. > > >>>>>>>>> > > >>>>>>>> I'd gotten the impression that Microsoft's intent is that > > >>>>>>>> when an application requires a particular version of the > > >>>>>>>> MSVCR library, the application vendor should ship that MSVCR > > >>>>>>>> library along with the application. > > >>>>>>>> > > >>>>>>>> Would it be possible to include that with the Windows install? > > >>>>>>>> > > >>>>>>>> Regards, > > >>>>>>>> > > >>>>>>>> -Martin > > >>>>>>>> > > >>>>>>> -- > > >>>>>>> Alan Knight [|], Engineering Manager, Cincom Smalltalk > > >>>>>>> [hidden email] [hidden email] > > http://www.cincomsmalltalk.com > > >>>>>>> <http://www.cincomsmalltalk.com/> > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>> _______________________________________________ > > >>>> vwnc mailing list > > >>>> [hidden email] > > >>>> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > > >>>> > > >>>> > > >>> > > >>> > > >>> _______________________________________________ > > >>> vwnc mailing list > > >>> [hidden email] > > >>> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > > >>> > > >>> > > >>> > > >> > > >> > > > > > > _______________________________________________ > > > vwnc mailing list > > > [hidden email] > > > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > > > > _______________________________________________ > > vwnc mailing list > > [hidden email] > > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: [now vw7.9] msvcr100.dll Re: vw7.8 64-bit onwindows error
|
|
In reply to this post by Boris Popov, DeepCove Labs (SNN)
Boris
I guess I should ask, how badly broken is it? I am currently upgrading our application and we use SSL and HTTPS. I would really like to use 7.9 as it fixes several problems. Terry =========================================================== Terry Raymond Crafted Smalltalk 80 Lazywood Ln. Tiverton, RI 02878 (401) 624-4517 [hidden email] =========================================================== > -----Original Message----- > From: Boris Popov, DeepCove Labs [mailto:[hidden email]] > Sent: Monday, July 16, 2012 8:24 AM > To: Terry Raymond > Cc: VWNC List > Subject: RE: [vwnc] [now vw7.9] msvcr100.dll Re: vw7.8 64-bit onwindows > error > > Terry, > > With the move to TLS, the framework is no longer able to connect to a subset > of SSL endpoints. It's a messy issue that OpenSSL and web browsers tend to > deal with by detecting various breakages and renegotiating or simply ignoring > some inconsistencies in the server implementations. See a thread titled > "[apr12.3] Xtreams.Incomplete" in vw-dev and the likes of > http://www.imperialviolet.org/2011/02/04/oppractices.html and > http://www.imperialviolet.org/2012/06/08/tlsversions.html for more > information. I do believe Martin has a high priority AR to address this, there's > just only so much they could do before 7.9's release. > > HTH, > > -Boris > > -----Original Message----- > From: Terry Raymond [mailto:[hidden email]] > Sent: Monday, July 16, 2012 8:15 AM > To: Boris Popov, DeepCove Labs > Cc: 'VWNC List' > Subject: RE: [vwnc] [now vw7.9] msvcr100.dll Re: vw7.8 64-bit onwindows > error > > Boris > > What are the compatibility problems with TLS/SSL? > > Terry > > ========================================================== > = > Terry Raymond > Crafted Smalltalk > 80 Lazywood Ln. > Tiverton, RI 02878 > (401) 624-4517 [hidden email] > ========================================================== > = > > > -----Original Message----- > > From: [hidden email] [mailto:[hidden email]] On > > Behalf Of Boris Popov, DeepCove Labs > > Sent: Sunday, July 15, 2012 9:51 PM > > To: Carl Gundel > > Cc: VWNC List > > Subject: Re: [vwnc] [now vw7.9] msvcr100.dll Re: vw7.8 64-bit > > onwindows error > > > > Don't worry, you're not the only one stuck on 7.8(.1); for us the > > issues with TLS/SSL compatibility make the move impossible at this > > point. Let's see what > > 7.10 brings us. > > > > -Boris > > > > On 2012-07-15, at 20:32, "Carl Gundel" <[hidden email]> wrote: > > > > > Niall, > > > > > > Thanks for the clarification. So if the question is "is it okay > > > that msvcr100.dll > > needs to distributed with VisualWorks?" > > > > > > For me the answer would have to be no. Telling my customers that > > > they > > now need to include this DLL represents a broken promise. > > > > > > It is not possible to statically link the needed functions because > > > these > > functions may become broken? Or is it possible but inconvenient? But > > the msvcr100.dll may also become broken? > > > > > > I'm not sure why Microsoft doesn't simply provide this DLL and keep > > > it up > > to date using Windows Update. > > > > > > So I'll be stuck with VW7.8 until it no longer works. I hope that > > > will be a very > > long time coming. > > > > > > -Carl Gundel > > > Liberty BASIC for Windows - http://www.libertybasic.com Run BASIC, > > > easy web programming - http://www.runbasic.com > > > > > > On Jul 15, 2012, at 5:21 PM, Niall Ross <[hidden email]> wrote: > > > > > >> Dear Carl, Christian, David et al, > > >> the msvcr100.dll does not have to be installed in a system location. > > >> > > >> For example, the 7.9 VW installer puts it in the system location if > > >> it can > > write to that location. If it cannot, it puts dll in VW's bin/win > > (and 64bit in bin/win64). Similarly, any app installer can put the > > dll in the same location as their VM or single file .exe. > > >> > > >> A local msvcr100.dll acts > > >> > > >> - as the one used by our VM if no system one is installed on that > > >> platform > > >> > > >> - as a softlink to the system one if present: our VM always uses > > >> the system one if present > > >> > > >> As of VS2010, Microsoft no longer include the dll in its base > > >> platforms. This is the change we are responding to - the > > >> corresponding prior versions have always been there by default so > > >> we never had to install them. (Actually, the dll is there,but > > >> hidden, only for MS internal stuff and not promised to remain > > >> compatible.) Thus the VS2010 and later dll has to be either > > >> - installed in system > > >> or > > >> - installed locally > > >> or > > >> - statically linked > > >> > > >> So the corresponding single-file .exe options are: > > >> > > >> a) "the full install dance" - almost certainly what you don't want > > >> to do if you're using the single file option > > >> > > >> b) Have your zip expand to YourApp.exe and msvcr100.dll, not just > > >> YourApp.exe. As noted, if your customer later installs or upgrade > > >> a system msvcr100.dll, it will all still work. (If you want, you > > >> can have your installation notes tell the user: "If you can put > > >> our msvcr100.dll in the bin and the .exe still works, leave it in > > >> the bin > > >> - you don't need it." This merely saves them ~750K of space; no > > >> other point.) > > >> > > >> c) Statically-link the dll to the VM: the difference from (b) is > > >> that if the > > user upgrades their platform, you will not upgrade with it, so we're > > not starting by encouraging this option. We're hoping our customers > > will say that > > (b) is OK. > > >> > > >> (The relevant Microsoft team promise future backward compatibility > > >> of the dll in all cases but discovery of major security hole.) > > >> > > >> HTH > > >> Niall Ross > > >> > > >> > > >>> Yes, this is going to be a show-stopper for using VW 7.9 for me as > > >>> well :-( > > >>> > > >>> But since linking the DLLs statically to the VMs for Windows needs > > >>> to be > > done only once, maybe somebody did this and could share the VM with > > the community? > > >>> > > >>> I wonder why Cincom is not able to provide such a VM... Is it so > > >>> hard to > > do or are there legal issues involved? > > >>> > > >>> I really hope that there will be a practical solution to this > > >>> problem > > without having to dive into C land to figure out how to do that myself... > > >>> > > >>> Christian > > >>> > > >>> > > >>>> -----Ursprüngliche Nachricht----- > > >>>> Von: [hidden email] [mailto:vwnc- > [hidden email]] > > Im > > >>>> Auftrag von Carl Gundel > > >>>> Gesendet: Sonntag, 15. Juli 2012 06:31 > > >>>> An: VWNC List > > >>>> Betreff: [vwnc] [now vw7.9] msvcr100.dll Re: vw7.8 64-bit on > > >>>> windows error > > >>>> > > >>>>> From the 7.9 release notes: > > >>>> > > >>>> "Windows OE DLL Requirement > > >>>> Due to a compiler upgrade, the Windows VMs require that > > >>>> msvcr100.dll be installed in its proper location (System32 or > > >>>> SysWOW64).If this DLL is not already installed, the installer > > >>>> installs and runs a program (VisualWorks32bitDLLPrereqs, and > > >>>> VisualWorks64bitDLLPrereqs on 64-bit > > >>>> systems) that installs the DLL(s) and registers VisualWorks' > > >>>> interest in > > them. > > >>>> After installation, an information screen tells you this has been > > >>>> done. If you uninstall this program, VisualWorks is deregistered > > >>>> for it, and the DLL is removed if no other program has an interest. > > >>>> When deploying an application with the VM, you are responsible > > >>>> for ensuring that this file is present on the target system." > > >>>> > > >>>> So, this is now required for 32-bit VisualWorks on Windows also? > > >>>> > > >>>> This is going to be very, very inconvenient for me. The single > > >>>> file VM and the ability to embed the image in the VM are one of > > >>>> the reasons I chose VisualWorks. Up to this point I have not > > >>>> needed any extra libraries and this is very important to me and > > >>>> to my customers. The msvcr100.dll throws a real monkey wrench > > >>>> into things for me. I hope that Cincom will decide to statically > > >>>> link whatever functions it needs from this DLL going forward. I > > >>>> may be > > forced to stick with 7.8 otherwise. > > >>>> > > >>>> -Carl Gundel > > >>>> http://www.libertybasic.com > > >>>> http://www.runbasic.com > > >>>> > > >>>> On Sun, Feb 20, 2011 at 10:29 AM, Alan Knight <[hidden email]> > > wrote: > > >>>> > > >>>>> Yes, this is expected. We'll need to do something about that, > > >>>>> but for 7.8, where win64 is in preview, I think it's likely to > > >>>>> remain and we'll sort out the various possibilities with a bit > > >>>>> more time to > > consider. > > >>>>> > > >>>>> > > >>>>> On 11-02-20 6:36 AM, Steffen Märcker wrote: > > >>>>> > > >>>>>> I've just attempted to start the win64 vm on Windows 7 Prof. 64 > > >>>>>> Bit and got the message to install msvcr100.dll too. Do I > > >>>>>> understand this thread right that this is actually expected? > > >>>>>> > > >>>>>> Regards, Steffen > > >>>>>> > > >>>>>> > > >>>>>> Am 11.02.2011, 11:17 Uhr, schrieb Steven Kelly > > <[hidden email]>: > > >>>>>> > > >>>>>> > > >>>>>>> I just went through all VW monolithic VMs from 2.0 to 7.7.1 > > >>>>>>> with Dependency Walker: > > >>>>>>> > > >>>>>>> 2.0 and 2.5 statically linked any functions they called from > > >>>>>>> msvcrt.dll > > >>>>>>> > > >>>>>>> 3.0 dynamically linked msvcrt40.dll, but 3.0b already changed > > >>>>>>> that to just msvcrt.dll. > > >>>>>>> > > >>>>>>> 5i.3 - 7.7.1 have all dynamically linked msvcrt.dll, which has > > >>>>>>> been an obligatory part of standard Windows installs for over > > >>>>>>> a decade > > >>>>>>> > > <http://en.wikipedia.org/wiki/Microsoft_Windows_library_files#Ms > > >>>>>>> vcrt > > >>>>>>> .dll > > >>>>>>> > > >>>>>>>> (Windows 2000 on), in Windows\system32 (and before that part > > of > > >>>>>>>> a > > >>>>>>>> > > >>>>>>> normal Windows install since at least Windows 95 > > >>>>>>> <http://support.microsoft.com/kb/895959> ). > > >>>>>>> > > >>>>>>> > > >>>>>>> There's a big difference > > >>>>>>> <http://msdn.microsoft.com/en- > > >>>>>>> > > >>>> us/library/abx4dbyh(VS.71).aspx#CodeSp > > >>>> > > >>>>>>> ippe > > >>>>>>> t0> between msvcrt.dll (a system file) and msvcr[71-100].dll. > > >>>>>>> t0> The > > >>>>>>> former is guaranteed to be found (although you have no control > > >>>>>>> over the exact version), the latter must be installed with > > >>>>>>> your > > application. > > >>>>>>> > > >>>>>>> > > >>>>>>> In theory you shouldn't rely on the system msvcrt.dll, since > > >>>>>>> it will be a different version from what you used in your own > > >>>>>>> testing, but in practice for VW this seems to have worked well. > > >>>>>>> I imagine VW's reliance is pretty generic and stable, so it's > > >>>>>>> been more likely that things improved when MS shipped an > > >>>>>>> update to msvcrt.dll, than that things would break. XP SP2 was > > >>>>>>> the exception, as the significant changes it introduced caused > > >>>>>>> problems in many applications. It looks like Microsoft are > > >>>>>>> moving away from allowing 3rd party apps to dynamically link > > >>>>>>> to the system msvcrt.dll, so Cincom should stop too. There's a > > >>>>>>> good discussion > > >>>>>>> <http://stackoverflow.com/questions/1073509/should-i-redistrib > > >>>>>>> ut > > >>>>>>> e-ms > > >>>>>>> vcrt > > >>>>>>> -dll-with-my-application> on the pros and cons on > StackOverflow. > > >>>>>>> > > >>>>>>> > > >>>>>>> So, with the exception of 3.0 (which was corrected in 3.0b), > > >>>>>>> no previous VM has dynamically depended on a particular > > >>>>>>> msvcr[40-100].dll. Those particular DLLs aren't shipped with > > >>>>>>> Windows, and if you depend on them you MUST ship them. > > >>>>>>> > > >>>>>>> > > >>>>>>> Better though would be to statically link the CRT for the > > >>>>>>> 64-bit VM, using /MT. That would also seem to be good advice > > >>>>>>> for the 32-bit VM, to remove the dependency on the system > msvcrt.dll. > > >>>>>>> Statically linking the 64-bit VM will also significantly > > >>>>>>> reduce the total size of the application, since I imagine VW > > >>>>>>> only uses a tiny fraction of the whole msvcrt100.dll. > > >>>>>>> > > >>>>>>> > > >>>>>>> Cheers, > > >>>>>>> > > >>>>>>> Steve > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> From: [hidden email] [mailto:vw-dev- > > >>>>>>> > > >>>> [hidden email]] > > >>>> > > >>>>>>> On Behalf Of Alan Knight > > >>>>>>> Sent: 11. helmikuuta 2011 1:34 > > >>>>>>> To: [hidden email] > > >>>>>>> Subject: Re: vw7.8 64-bit on windows error > > >>>>>>> > > >>>>>>> > > >>>>>>> I don't think we have statically linked the MSVCR libraries in > > >>>>>>> previous versions, at least not for a very long time. I also > > >>>>>>> don't think that those libraries are part of the Windows > > >>>>>>> installs, but they tended to be there if you'd installed > > >>>>>>> anything at all. And possibly if the operating system included > > >>>>>>> programs that were built with those compilers they would be > > >>>>>>> for > > practical purposes included. > > >>>>>>> The difference in this case is, I suspect, that people have > > >>>>>>> fewer things installed that are 64-bit applications, and the > > >>>>>>> compiler > > is newer. > > >>>>>>> > > >>>>>>> It is not needed on 32-bit installations, because we are for > > >>>>>>> the moment still using an older compiler version for the > > >>>>>>> 32-bit versions, partly because of that dependency. Building > > >>>>>>> the 64-bit versions required the use of the more recent > > >>>>>>> compiler. 32-bit versions appear to my untrained eye to > > >>>>>>> require MSVCRT.DLL with no version number embedded in the > > >>>>>>> name. I don't believe it makes any > > >>>>>>> > > >>>> difference between visual.exe and vwnt.exe. > > >>>> > > >>>>>>> It's possible that we really ought to be installing it, but it > > >>>>>>> is not something we've ever done in the past and it does not > > >>>>>>> seem to have previously been an issue. > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> In earlier versions, the necessary parts of the MSVCR library > > >>>>>>> have been statically linked (IIRC), or then the relevant > > >>>>>>> library has been part of a normal Windows installation anyway > > >>>>>>> (maybe in IE?). Even the Cairo DLL was kindly made by Travis > > >>>>>>> to be statically linked rather than require > > >>>>>>> MSCVR90.dll: > > >>>>>>> > > >>>>>>> http://www.parcplace.net/list/vwnc- > archive/0910/msg00085.html > > >>>>>>> > > >>>>>>> Information on static linking and msvcr100.dll is in the last > > >>>>>>> message > > >>>>>>> here: > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>> > > http://social.msdn.microsoft.com/Forums/en/vssetup/thread/6891665f- > > >>>> f > > >>>> > > >>>>>>> d83- > > >>>>>>> 426a-9d73-69d6d7e171a3 > > >>>>>>> > > >>>>>>> > > >>>>>>> As Martin said, a vendor using a redistributable dynamically > > >>>>>>> linked library like this is expected to ship it as part of > > >>>>>>> their installer > > >>>>>>> - as can be seen from e.g. InstallShield, which comes with a > > >>>>>>> wide range of redistributables that install builders can add > > >>>>>>> to their install. It's also what Microsoft says to do (IIUC): > > >>>>>>> > > >>>>>>> http://msdn.microsoft.com/en-us/library/ms235299.aspx > > >>>>>>> > > >>>>>>> "If you use a merge module that contains a Visual C++ DLL, you > > >>>>>>> must include it in the Windows Installer package (or similar > > >>>>>>> installation > > >>>>>>> package) that you are using to deploy the application" > > >>>>>>> > > >>>>>>> > > >>>>>>> Of course, all this is just for what Cincom should do when > > >>>>>>> providing their product, if that product were just an > > >>>>>>> application. Given the product in this case is a development > > >>>>>>> environment, Cincom should also provide automation and/or > > >>>>>>> instructions for developers to create and deploy their own > > >>>>>>> products - including any necessary > > >>>>>>> > > >>>> redistributables. > > >>>> > > >>>>>>> Otherwise end users are going to be reporting that the > > >>>>>>> application doesn't work, and developers aren't going to > > >>>>>>> understand why (and presumably Cincom isn't going to get any > > royalties in that case!). > > >>>>>>> > > >>>>>>> > > >>>>>>> Is msvcr100.dll also needed on 32-bit VW 7.8 installations on > > Windows? > > >>>>>>> Does it make a difference if we use the monolithic visual.exe > > >>>>>>> VM or the split .exe+.dll VM? > > >>>>>>> > > >>>>>>> > > >>>>>>> Cheers, > > >>>>>>> > > >>>>>>> Steve > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> ________________________________ > > >>>>>>> > > >>>>>>> From: [hidden email] on behalf of Alan Knight > > >>>>>>> Sent: Thu 10/02/2011 19:55 > > >>>>>>> To: Martin McClure > > >>>>>>> Cc: [hidden email] > > >>>>>>> Subject: Re: vw7.8 64-bit on windows error > > >>>>>>> > > >>>>>>> > > >>>>>>> That isn't something we've done in the past. I think that > > >>>>>>> typically those libraries end up installed quite widely as > > >>>>>>> soon as you've installed anything. And it would be a bit > > >>>>>>> tricky, in that it wouldn't be integrated with our installation > mechanisms. > > >>>>>>> I think about the best we could do at this point would be to > > >>>>>>> include a copy on the CD or download and people would have to > > >>>>>>> install it themselves. We can also look into trying to do > > >>>>>>> something in the next release when we expect to have Win64 as > > >>>>>>> fully supported, but it's quite > > >>>>>>> > > >>>> late to try much for this one. > > >>>> > > >>>>>>> On 2011-02-10 12:09 AM, Martin McClure wrote: > > >>>>>>> > > >>>>>>>> On 02/09/11 11:11, Alan Knight wrote: > > >>>>>>>> > > >>>>>>>>> you need to install the appropriate MS runtime for the most > > >>>>>>>>> recent compiler. > > >>>>>>>>> > > >>>>>>>> I'd gotten the impression that Microsoft's intent is that > > >>>>>>>> when an application requires a particular version of the > > >>>>>>>> MSVCR library, the application vendor should ship that MSVCR > > >>>>>>>> library along with the application. > > >>>>>>>> > > >>>>>>>> Would it be possible to include that with the Windows install? > > >>>>>>>> > > >>>>>>>> Regards, > > >>>>>>>> > > >>>>>>>> -Martin > > >>>>>>>> > > >>>>>>> -- > > >>>>>>> Alan Knight [|], Engineering Manager, Cincom Smalltalk > > >>>>>>> [hidden email] [hidden email] > > http://www.cincomsmalltalk.com > > >>>>>>> <http://www.cincomsmalltalk.com/> > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>> _______________________________________________ > > >>>> vwnc mailing list > > >>>> [hidden email] > > >>>> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > > >>>> > > >>>> > > >>> > > >>> > > >>> _______________________________________________ > > >>> vwnc mailing list > > >>> [hidden email] > > >>> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > > >>> > > >>> > > >>> > > >> > > >> > > > > > > _______________________________________________ > > > vwnc mailing list > > > [hidden email] > > > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > > > > _______________________________________________ > > vwnc mailing list > > [hidden email] > > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: [now vw7.9] msvcr100.dll Re: vw7.8 64-bit onwindows error
|
|
In reply to this post by Terry Raymond
Terry,
No, it wasn't worth it in my mind, I didn't see anything in 7.9 that nudged me to want to migrate desperately. -Boris -----Original Message----- From: Terry Raymond [mailto:[hidden email]] Sent: Monday, July 16, 2012 8:58 AM To: Boris Popov, DeepCove Labs Cc: 'VWNC List' Subject: RE: [vwnc] [now vw7.9] msvcr100.dll Re: vw7.8 64-bit onwindows error Boris Did you try a partial upgrade, i.e. use a 7.9 base but use 7.8.1 Net parcels? Terry =========================================================== Terry Raymond Crafted Smalltalk 80 Lazywood Ln. Tiverton, RI 02878 (401) 624-4517 [hidden email] =========================================================== > -----Original Message----- > From: Boris Popov, DeepCove Labs [mailto:[hidden email]] > Sent: Monday, July 16, 2012 8:24 AM > To: Terry Raymond > Cc: VWNC List > Subject: RE: [vwnc] [now vw7.9] msvcr100.dll Re: vw7.8 64-bit > onwindows error > > Terry, > > With the move to TLS, the framework is no longer able to connect to a > subset of SSL endpoints. It's a messy issue that OpenSSL and web > browsers tend to deal with by detecting various breakages and > renegotiating or simply ignoring some inconsistencies in the server > implementations. See a thread titled "[apr12.3] Xtreams.Incomplete" in > vw-dev and the likes of > http://www.imperialviolet.org/2011/02/04/oppractices.html and > http://www.imperialviolet.org/2012/06/08/tlsversions.html for more > information. I do believe Martin has a high priority AR to address this, there's just only so much they could do before 7.9's release. > > HTH, > > -Boris > > -----Original Message----- > From: Terry Raymond [mailto:[hidden email]] > Sent: Monday, July 16, 2012 8:15 AM > To: Boris Popov, DeepCove Labs > Cc: 'VWNC List' > Subject: RE: [vwnc] [now vw7.9] msvcr100.dll Re: vw7.8 64-bit > onwindows error > > Boris > > What are the compatibility problems with TLS/SSL? > > Terry > > ========================================================== > = > Terry Raymond > Crafted Smalltalk > 80 Lazywood Ln. > Tiverton, RI 02878 > (401) 624-4517 [hidden email] > ========================================================== > = > > > -----Original Message----- > > From: [hidden email] [mailto:[hidden email]] On > > Behalf Of Boris Popov, DeepCove Labs > > Sent: Sunday, July 15, 2012 9:51 PM > > To: Carl Gundel > > Cc: VWNC List > > Subject: Re: [vwnc] [now vw7.9] msvcr100.dll Re: vw7.8 64-bit > > onwindows error > > > > Don't worry, you're not the only one stuck on 7.8(.1); for us the > > issues with TLS/SSL compatibility make the move impossible at this > > point. Let's see what > > 7.10 brings us. > > > > -Boris > > > > On 2012-07-15, at 20:32, "Carl Gundel" <[hidden email]> wrote: > > > > > Niall, > > > > > > Thanks for the clarification. So if the question is "is it okay > > > that msvcr100.dll > > needs to distributed with VisualWorks?" > > > > > > For me the answer would have to be no. Telling my customers that > > > they > > now need to include this DLL represents a broken promise. > > > > > > It is not possible to statically link the needed functions because > > > these > > functions may become broken? Or is it possible but inconvenient? > > But the msvcr100.dll may also become broken? > > > > > > I'm not sure why Microsoft doesn't simply provide this DLL and > > > keep it up > > to date using Windows Update. > > > > > > So I'll be stuck with VW7.8 until it no longer works. I hope that > > > will be a very > > long time coming. > > > > > > -Carl Gundel > > > Liberty BASIC for Windows - http://www.libertybasic.com Run BASIC, > > > easy web programming - http://www.runbasic.com > > > > > > On Jul 15, 2012, at 5:21 PM, Niall Ross <[hidden email]> wrote: > > > > > >> Dear Carl, Christian, David et al, the msvcr100.dll does not > > >> have to be installed in a system location. > > >> > > >> For example, the 7.9 VW installer puts it in the system location > > >> if it can > > write to that location. If it cannot, it puts dll in VW's bin/win > > (and 64bit in bin/win64). Similarly, any app installer can put the > > dll in the same location as their VM or single file .exe. > > >> > > >> A local msvcr100.dll acts > > >> > > >> - as the one used by our VM if no system one is installed on > > >> that platform > > >> > > >> - as a softlink to the system one if present: our VM always > > >> uses the system one if present > > >> > > >> As of VS2010, Microsoft no longer include the dll in its base > > >> platforms. This is the change we are responding to - the > > >> corresponding prior versions have always been there by default so > > >> we never had to install them. (Actually, the dll is there,but > > >> hidden, only for MS internal stuff and not promised to remain > > >> compatible.) Thus the VS2010 and later dll has to be either > > >> - installed in system > > >> or > > >> - installed locally > > >> or > > >> - statically linked > > >> > > >> So the corresponding single-file .exe options are: > > >> > > >> a) "the full install dance" - almost certainly what you don't > > >> want to do if you're using the single file option > > >> > > >> b) Have your zip expand to YourApp.exe and msvcr100.dll, not just > > >> YourApp.exe. As noted, if your customer later installs or > > >> upgrade a system msvcr100.dll, it will all still work. (If you > > >> want, you can have your installation notes tell the user: "If > > >> you can put our msvcr100.dll in the bin and the .exe still works, > > >> leave it in the bin > > >> - you don't need it." This merely saves them ~750K of space; no > > >> other point.) > > >> > > >> c) Statically-link the dll to the VM: the difference from (b) is > > >> that if the > > user upgrades their platform, you will not upgrade with it, so we're > > not starting by encouraging this option. We're hoping our customers > > will say that > > (b) is OK. > > >> > > >> (The relevant Microsoft team promise future backward > > >> compatibility of the dll in all cases but discovery of major > > >> security hole.) > > >> > > >> HTH > > >> Niall Ross > > >> > > >> > > >>> Yes, this is going to be a show-stopper for using VW 7.9 for me > > >>> as well :-( > > >>> > > >>> But since linking the DLLs statically to the VMs for Windows > > >>> needs to be > > done only once, maybe somebody did this and could share the VM with > > the community? > > >>> > > >>> I wonder why Cincom is not able to provide such a VM... Is it so > > >>> hard to > > do or are there legal issues involved? > > >>> > > >>> I really hope that there will be a practical solution to this > > >>> problem > > without having to dive into C land to figure out how to do that myself... > > >>> > > >>> Christian > > >>> > > >>> > > >>>> -----Ursprüngliche Nachricht----- > > >>>> Von: [hidden email] [mailto:vwnc- > [hidden email]] > > Im > > >>>> Auftrag von Carl Gundel > > >>>> Gesendet: Sonntag, 15. Juli 2012 06:31 > > >>>> An: VWNC List > > >>>> Betreff: [vwnc] [now vw7.9] msvcr100.dll Re: vw7.8 64-bit on > > >>>> windows error > > >>>> > > >>>>> From the 7.9 release notes: > > >>>> > > >>>> "Windows OE DLL Requirement > > >>>> Due to a compiler upgrade, the Windows VMs require that > > >>>> msvcr100.dll be installed in its proper location (System32 or > > >>>> SysWOW64).If this DLL is not already installed, the installer > > >>>> installs and runs a program (VisualWorks32bitDLLPrereqs, and > > >>>> VisualWorks64bitDLLPrereqs on 64-bit > > >>>> systems) that installs the DLL(s) and registers VisualWorks' > > >>>> interest in > > them. > > >>>> After installation, an information screen tells you this has > > >>>> been done. If you uninstall this program, VisualWorks is > > >>>> deregistered for it, and the DLL is removed if no other program has an interest. > > >>>> When deploying an application with the VM, you are responsible > > >>>> for ensuring that this file is present on the target system." > > >>>> > > >>>> So, this is now required for 32-bit VisualWorks on Windows also? > > >>>> > > >>>> This is going to be very, very inconvenient for me. The single > > >>>> file VM and the ability to embed the image in the VM are one of > > >>>> the reasons I chose VisualWorks. Up to this point I have not > > >>>> needed any extra libraries and this is very important to me and > > >>>> to my customers. The msvcr100.dll throws a real monkey wrench > > >>>> into things for me. I hope that Cincom will decide to > > >>>> statically link whatever functions it needs from this DLL going > > >>>> forward. I may be > > forced to stick with 7.8 otherwise. > > >>>> > > >>>> -Carl Gundel > > >>>> http://www.libertybasic.com > > >>>> http://www.runbasic.com > > >>>> > > >>>> On Sun, Feb 20, 2011 at 10:29 AM, Alan Knight <[hidden email]> > > wrote: > > >>>> > > >>>>> Yes, this is expected. We'll need to do something about that, > > >>>>> but for 7.8, where win64 is in preview, I think it's likely to > > >>>>> remain and we'll sort out the various possibilities with a bit > > >>>>> more time to > > consider. > > >>>>> > > >>>>> > > >>>>> On 11-02-20 6:36 AM, Steffen Märcker wrote: > > >>>>> > > >>>>>> I've just attempted to start the win64 vm on Windows 7 Prof. > > >>>>>> 64 Bit and got the message to install msvcr100.dll too. Do I > > >>>>>> understand this thread right that this is actually expected? > > >>>>>> > > >>>>>> Regards, Steffen > > >>>>>> > > >>>>>> > > >>>>>> Am 11.02.2011, 11:17 Uhr, schrieb Steven Kelly > > <[hidden email]>: > > >>>>>> > > >>>>>> > > >>>>>>> I just went through all VW monolithic VMs from 2.0 to 7.7.1 > > >>>>>>> with Dependency Walker: > > >>>>>>> > > >>>>>>> 2.0 and 2.5 statically linked any functions they called from > > >>>>>>> msvcrt.dll > > >>>>>>> > > >>>>>>> 3.0 dynamically linked msvcrt40.dll, but 3.0b already > > >>>>>>> changed that to just msvcrt.dll. > > >>>>>>> > > >>>>>>> 5i.3 - 7.7.1 have all dynamically linked msvcrt.dll, which > > >>>>>>> has been an obligatory part of standard Windows installs for > > >>>>>>> over a decade > > >>>>>>> > > <http://en.wikipedia.org/wiki/Microsoft_Windows_library_files#Ms > > >>>>>>> vcrt > > >>>>>>> .dll > > >>>>>>> > > >>>>>>>> (Windows 2000 on), in Windows\system32 (and before that > > >>>>>>>> part > > of > > >>>>>>>> a > > >>>>>>>> > > >>>>>>> normal Windows install since at least Windows 95 > > >>>>>>> <http://support.microsoft.com/kb/895959> ). > > >>>>>>> > > >>>>>>> > > >>>>>>> There's a big difference > > >>>>>>> <http://msdn.microsoft.com/en- > > >>>>>>> > > >>>> us/library/abx4dbyh(VS.71).aspx#CodeSp > > >>>> > > >>>>>>> ippe > > >>>>>>> t0> between msvcrt.dll (a system file) and msvcr[71-100].dll. > > >>>>>>> t0> The > > >>>>>>> former is guaranteed to be found (although you have no > > >>>>>>> control over the exact version), the latter must be > > >>>>>>> installed with your > > application. > > >>>>>>> > > >>>>>>> > > >>>>>>> In theory you shouldn't rely on the system msvcrt.dll, since > > >>>>>>> it will be a different version from what you used in your > > >>>>>>> own testing, but in practice for VW this seems to have worked well. > > >>>>>>> I imagine VW's reliance is pretty generic and stable, so > > >>>>>>> it's been more likely that things improved when MS shipped > > >>>>>>> an update to msvcrt.dll, than that things would break. XP > > >>>>>>> SP2 was the exception, as the significant changes it > > >>>>>>> introduced caused problems in many applications. It looks > > >>>>>>> like Microsoft are moving away from allowing 3rd party apps > > >>>>>>> to dynamically link to the system msvcrt.dll, so Cincom > > >>>>>>> should stop too. There's a good discussion > > >>>>>>> <http://stackoverflow.com/questions/1073509/should-i-redistr > > >>>>>>> ib > > >>>>>>> ut > > >>>>>>> e-ms > > >>>>>>> vcrt > > >>>>>>> -dll-with-my-application> on the pros and cons on > StackOverflow. > > >>>>>>> > > >>>>>>> > > >>>>>>> So, with the exception of 3.0 (which was corrected in 3.0b), > > >>>>>>> no previous VM has dynamically depended on a particular > > >>>>>>> msvcr[40-100].dll. Those particular DLLs aren't shipped with > > >>>>>>> Windows, and if you depend on them you MUST ship them. > > >>>>>>> > > >>>>>>> > > >>>>>>> Better though would be to statically link the CRT for the > > >>>>>>> 64-bit VM, using /MT. That would also seem to be good advice > > >>>>>>> for the 32-bit VM, to remove the dependency on the system > msvcrt.dll. > > >>>>>>> Statically linking the 64-bit VM will also significantly > > >>>>>>> reduce the total size of the application, since I imagine VW > > >>>>>>> only uses a tiny fraction of the whole msvcrt100.dll. > > >>>>>>> > > >>>>>>> > > >>>>>>> Cheers, > > >>>>>>> > > >>>>>>> Steve > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> From: [hidden email] [mailto:vw-dev- > > >>>>>>> > > >>>> [hidden email]] > > >>>> > > >>>>>>> On Behalf Of Alan Knight > > >>>>>>> Sent: 11. helmikuuta 2011 1:34 > > >>>>>>> To: [hidden email] > > >>>>>>> Subject: Re: vw7.8 64-bit on windows error > > >>>>>>> > > >>>>>>> > > >>>>>>> I don't think we have statically linked the MSVCR libraries > > >>>>>>> in previous versions, at least not for a very long time. I > > >>>>>>> also don't think that those libraries are part of the > > >>>>>>> Windows installs, but they tended to be there if you'd > > >>>>>>> installed anything at all. And possibly if the operating > > >>>>>>> system included programs that were built with those > > >>>>>>> compilers they would be for > > practical purposes included. > > >>>>>>> The difference in this case is, I suspect, that people have > > >>>>>>> fewer things installed that are 64-bit applications, and the > > >>>>>>> compiler > > is newer. > > >>>>>>> > > >>>>>>> It is not needed on 32-bit installations, because we are for > > >>>>>>> the moment still using an older compiler version for the > > >>>>>>> 32-bit versions, partly because of that dependency. Building > > >>>>>>> the 64-bit versions required the use of the more recent > > >>>>>>> compiler. 32-bit versions appear to my untrained eye to > > >>>>>>> require MSVCRT.DLL with no version number embedded in the > > >>>>>>> name. I don't believe it makes any > > >>>>>>> > > >>>> difference between visual.exe and vwnt.exe. > > >>>> > > >>>>>>> It's possible that we really ought to be installing it, but > > >>>>>>> it is not something we've ever done in the past and it does > > >>>>>>> not seem to have previously been an issue. > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> In earlier versions, the necessary parts of the MSVCR > > >>>>>>> library have been statically linked (IIRC), or then the > > >>>>>>> relevant library has been part of a normal Windows > > >>>>>>> installation anyway (maybe in IE?). Even the Cairo DLL was > > >>>>>>> kindly made by Travis to be statically linked rather than > > >>>>>>> require > > >>>>>>> MSCVR90.dll: > > >>>>>>> > > >>>>>>> http://www.parcplace.net/list/vwnc- > archive/0910/msg00085.html > > >>>>>>> > > >>>>>>> Information on static linking and msvcr100.dll is in the > > >>>>>>> last message > > >>>>>>> here: > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>> > > http://social.msdn.microsoft.com/Forums/en/vssetup/thread/6891665f- > > >>>> f > > >>>> > > >>>>>>> d83- > > >>>>>>> 426a-9d73-69d6d7e171a3 > > >>>>>>> > > >>>>>>> > > >>>>>>> As Martin said, a vendor using a redistributable dynamically > > >>>>>>> linked library like this is expected to ship it as part of > > >>>>>>> their installer > > >>>>>>> - as can be seen from e.g. InstallShield, which comes with a > > >>>>>>> wide range of redistributables that install builders can add > > >>>>>>> to their install. It's also what Microsoft says to do (IIUC): > > >>>>>>> > > >>>>>>> http://msdn.microsoft.com/en-us/library/ms235299.aspx > > >>>>>>> > > >>>>>>> "If you use a merge module that contains a Visual C++ DLL, > > >>>>>>> you must include it in the Windows Installer package (or > > >>>>>>> similar installation > > >>>>>>> package) that you are using to deploy the application" > > >>>>>>> > > >>>>>>> > > >>>>>>> Of course, all this is just for what Cincom should do when > > >>>>>>> providing their product, if that product were just an > > >>>>>>> application. Given the product in this case is a development > > >>>>>>> environment, Cincom should also provide automation and/or > > >>>>>>> instructions for developers to create and deploy their own > > >>>>>>> products - including any necessary > > >>>>>>> > > >>>> redistributables. > > >>>> > > >>>>>>> Otherwise end users are going to be reporting that the > > >>>>>>> application doesn't work, and developers aren't going to > > >>>>>>> understand why (and presumably Cincom isn't going to get any > > royalties in that case!). > > >>>>>>> > > >>>>>>> > > >>>>>>> Is msvcr100.dll also needed on 32-bit VW 7.8 installations > > >>>>>>> on > > Windows? > > >>>>>>> Does it make a difference if we use the monolithic > > >>>>>>> visual.exe VM or the split .exe+.dll VM? > > >>>>>>> > > >>>>>>> > > >>>>>>> Cheers, > > >>>>>>> > > >>>>>>> Steve > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> ________________________________ > > >>>>>>> > > >>>>>>> From: [hidden email] on behalf of Alan Knight > > >>>>>>> Sent: Thu 10/02/2011 19:55 > > >>>>>>> To: Martin McClure > > >>>>>>> Cc: [hidden email] > > >>>>>>> Subject: Re: vw7.8 64-bit on windows error > > >>>>>>> > > >>>>>>> > > >>>>>>> That isn't something we've done in the past. I think that > > >>>>>>> typically those libraries end up installed quite widely as > > >>>>>>> soon as you've installed anything. And it would be a bit > > >>>>>>> tricky, in that it wouldn't be integrated with our > > >>>>>>> installation > mechanisms. > > >>>>>>> I think about the best we could do at this point would be to > > >>>>>>> include a copy on the CD or download and people would have > > >>>>>>> to install it themselves. We can also look into trying to do > > >>>>>>> something in the next release when we expect to have Win64 > > >>>>>>> as fully supported, but it's quite > > >>>>>>> > > >>>> late to try much for this one. > > >>>> > > >>>>>>> On 2011-02-10 12:09 AM, Martin McClure wrote: > > >>>>>>> > > >>>>>>>> On 02/09/11 11:11, Alan Knight wrote: > > >>>>>>>> > > >>>>>>>>> you need to install the appropriate MS runtime for the > > >>>>>>>>> most recent compiler. > > >>>>>>>>> > > >>>>>>>> I'd gotten the impression that Microsoft's intent is that > > >>>>>>>> when an application requires a particular version of the > > >>>>>>>> MSVCR library, the application vendor should ship that > > >>>>>>>> MSVCR library along with the application. > > >>>>>>>> > > >>>>>>>> Would it be possible to include that with the Windows install? > > >>>>>>>> > > >>>>>>>> Regards, > > >>>>>>>> > > >>>>>>>> -Martin > > >>>>>>>> > > >>>>>>> -- > > >>>>>>> Alan Knight [|], Engineering Manager, Cincom Smalltalk > > >>>>>>> [hidden email] [hidden email] > > http://www.cincomsmalltalk.com > > >>>>>>> <http://www.cincomsmalltalk.com/> > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>> _______________________________________________ > > >>>> vwnc mailing list > > >>>> [hidden email] > > >>>> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > > >>>> > > >>>> > > >>> > > >>> > > >>> _______________________________________________ > > >>> vwnc mailing list > > >>> [hidden email] > > >>> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > > >>> > > >>> > > >>> > > >> > > >> > > > > > > _______________________________________________ > > > vwnc mailing list > > > [hidden email] > > > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > > > > _______________________________________________ > > vwnc mailing list > > [hidden email] > > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: [now vw7.9] msvcr100.dll Re: vw7.8 64-bit onwindows error
|
|
In reply to this post by Terry Raymond
Terry,
The simple answer is that it depends. Yes, I hate this exact type of answer myself, but it really is the case here. If you are needing to talk to a specific set of partners over SSL/TLS, say some APIs like AWS, you can easily test that they work and move on. But if your applications have any kind of web hook functionality where clients provide arbitrary URLs for you to call back to, then there's a good chance you'll come across a server sooner or later with which you're not able to negotiate a connection, but OpenSSL/Chrome/Firefox is. The links in my other email provide more details and some quantitative analysis from 2011. HTH, -Boris -----Original Message----- From: Terry Raymond [mailto:[hidden email]] Sent: Monday, July 16, 2012 9:00 AM To: Boris Popov, DeepCove Labs Cc: 'VWNC List' Subject: RE: [vwnc] [now vw7.9] msvcr100.dll Re: vw7.8 64-bit onwindows error Boris I guess I should ask, how badly broken is it? I am currently upgrading our application and we use SSL and HTTPS. I would really like to use 7.9 as it fixes several problems. Terry =========================================================== Terry Raymond Crafted Smalltalk 80 Lazywood Ln. Tiverton, RI 02878 (401) 624-4517 [hidden email] =========================================================== > -----Original Message----- > From: Boris Popov, DeepCove Labs [mailto:[hidden email]] > Sent: Monday, July 16, 2012 8:24 AM > To: Terry Raymond > Cc: VWNC List > Subject: RE: [vwnc] [now vw7.9] msvcr100.dll Re: vw7.8 64-bit > onwindows error > > Terry, > > With the move to TLS, the framework is no longer able to connect to a > subset of SSL endpoints. It's a messy issue that OpenSSL and web > browsers tend to deal with by detecting various breakages and > renegotiating or simply ignoring some inconsistencies in the server > implementations. See a thread titled "[apr12.3] Xtreams.Incomplete" in > vw-dev and the likes of > http://www.imperialviolet.org/2011/02/04/oppractices.html and > http://www.imperialviolet.org/2012/06/08/tlsversions.html for more > information. I do believe Martin has a high priority AR to address this, there's just only so much they could do before 7.9's release. > > HTH, > > -Boris > > -----Original Message----- > From: Terry Raymond [mailto:[hidden email]] > Sent: Monday, July 16, 2012 8:15 AM > To: Boris Popov, DeepCove Labs > Cc: 'VWNC List' > Subject: RE: [vwnc] [now vw7.9] msvcr100.dll Re: vw7.8 64-bit > onwindows error > > Boris > > What are the compatibility problems with TLS/SSL? > > Terry > > ========================================================== > = > Terry Raymond > Crafted Smalltalk > 80 Lazywood Ln. > Tiverton, RI 02878 > (401) 624-4517 [hidden email] > ========================================================== > = > > > -----Original Message----- > > From: [hidden email] [mailto:[hidden email]] On > > Behalf Of Boris Popov, DeepCove Labs > > Sent: Sunday, July 15, 2012 9:51 PM > > To: Carl Gundel > > Cc: VWNC List > > Subject: Re: [vwnc] [now vw7.9] msvcr100.dll Re: vw7.8 64-bit > > onwindows error > > > > Don't worry, you're not the only one stuck on 7.8(.1); for us the > > issues with TLS/SSL compatibility make the move impossible at this > > point. Let's see what > > 7.10 brings us. > > > > -Boris > > > > On 2012-07-15, at 20:32, "Carl Gundel" <[hidden email]> wrote: > > > > > Niall, > > > > > > Thanks for the clarification. So if the question is "is it okay > > > that msvcr100.dll > > needs to distributed with VisualWorks?" > > > > > > For me the answer would have to be no. Telling my customers that > > > they > > now need to include this DLL represents a broken promise. > > > > > > It is not possible to statically link the needed functions because > > > these > > functions may become broken? Or is it possible but inconvenient? > > But the msvcr100.dll may also become broken? > > > > > > I'm not sure why Microsoft doesn't simply provide this DLL and > > > keep it up > > to date using Windows Update. > > > > > > So I'll be stuck with VW7.8 until it no longer works. I hope that > > > will be a very > > long time coming. > > > > > > -Carl Gundel > > > Liberty BASIC for Windows - http://www.libertybasic.com Run BASIC, > > > easy web programming - http://www.runbasic.com > > > > > > On Jul 15, 2012, at 5:21 PM, Niall Ross <[hidden email]> wrote: > > > > > >> Dear Carl, Christian, David et al, the msvcr100.dll does not > > >> have to be installed in a system location. > > >> > > >> For example, the 7.9 VW installer puts it in the system location > > >> if it can > > write to that location. If it cannot, it puts dll in VW's bin/win > > (and 64bit in bin/win64). Similarly, any app installer can put the > > dll in the same location as their VM or single file .exe. > > >> > > >> A local msvcr100.dll acts > > >> > > >> - as the one used by our VM if no system one is installed on > > >> that platform > > >> > > >> - as a softlink to the system one if present: our VM always > > >> uses the system one if present > > >> > > >> As of VS2010, Microsoft no longer include the dll in its base > > >> platforms. This is the change we are responding to - the > > >> corresponding prior versions have always been there by default so > > >> we never had to install them. (Actually, the dll is there,but > > >> hidden, only for MS internal stuff and not promised to remain > > >> compatible.) Thus the VS2010 and later dll has to be either > > >> - installed in system > > >> or > > >> - installed locally > > >> or > > >> - statically linked > > >> > > >> So the corresponding single-file .exe options are: > > >> > > >> a) "the full install dance" - almost certainly what you don't > > >> want to do if you're using the single file option > > >> > > >> b) Have your zip expand to YourApp.exe and msvcr100.dll, not just > > >> YourApp.exe. As noted, if your customer later installs or > > >> upgrade a system msvcr100.dll, it will all still work. (If you > > >> want, you can have your installation notes tell the user: "If > > >> you can put our msvcr100.dll in the bin and the .exe still works, > > >> leave it in the bin > > >> - you don't need it." This merely saves them ~750K of space; no > > >> other point.) > > >> > > >> c) Statically-link the dll to the VM: the difference from (b) is > > >> that if the > > user upgrades their platform, you will not upgrade with it, so we're > > not starting by encouraging this option. We're hoping our customers > > will say that > > (b) is OK. > > >> > > >> (The relevant Microsoft team promise future backward > > >> compatibility of the dll in all cases but discovery of major > > >> security hole.) > > >> > > >> HTH > > >> Niall Ross > > >> > > >> > > >>> Yes, this is going to be a show-stopper for using VW 7.9 for me > > >>> as well :-( > > >>> > > >>> But since linking the DLLs statically to the VMs for Windows > > >>> needs to be > > done only once, maybe somebody did this and could share the VM with > > the community? > > >>> > > >>> I wonder why Cincom is not able to provide such a VM... Is it so > > >>> hard to > > do or are there legal issues involved? > > >>> > > >>> I really hope that there will be a practical solution to this > > >>> problem > > without having to dive into C land to figure out how to do that myself... > > >>> > > >>> Christian > > >>> > > >>> > > >>>> -----Ursprüngliche Nachricht----- > > >>>> Von: [hidden email] [mailto:vwnc- > [hidden email]] > > Im > > >>>> Auftrag von Carl Gundel > > >>>> Gesendet: Sonntag, 15. Juli 2012 06:31 > > >>>> An: VWNC List > > >>>> Betreff: [vwnc] [now vw7.9] msvcr100.dll Re: vw7.8 64-bit on > > >>>> windows error > > >>>> > > >>>>> From the 7.9 release notes: > > >>>> > > >>>> "Windows OE DLL Requirement > > >>>> Due to a compiler upgrade, the Windows VMs require that > > >>>> msvcr100.dll be installed in its proper location (System32 or > > >>>> SysWOW64).If this DLL is not already installed, the installer > > >>>> installs and runs a program (VisualWorks32bitDLLPrereqs, and > > >>>> VisualWorks64bitDLLPrereqs on 64-bit > > >>>> systems) that installs the DLL(s) and registers VisualWorks' > > >>>> interest in > > them. > > >>>> After installation, an information screen tells you this has > > >>>> been done. If you uninstall this program, VisualWorks is > > >>>> deregistered for it, and the DLL is removed if no other program has an interest. > > >>>> When deploying an application with the VM, you are responsible > > >>>> for ensuring that this file is present on the target system." > > >>>> > > >>>> So, this is now required for 32-bit VisualWorks on Windows also? > > >>>> > > >>>> This is going to be very, very inconvenient for me. The single > > >>>> file VM and the ability to embed the image in the VM are one of > > >>>> the reasons I chose VisualWorks. Up to this point I have not > > >>>> needed any extra libraries and this is very important to me and > > >>>> to my customers. The msvcr100.dll throws a real monkey wrench > > >>>> into things for me. I hope that Cincom will decide to > > >>>> statically link whatever functions it needs from this DLL going > > >>>> forward. I may be > > forced to stick with 7.8 otherwise. > > >>>> > > >>>> -Carl Gundel > > >>>> http://www.libertybasic.com > > >>>> http://www.runbasic.com > > >>>> > > >>>> On Sun, Feb 20, 2011 at 10:29 AM, Alan Knight <[hidden email]> > > wrote: > > >>>> > > >>>>> Yes, this is expected. We'll need to do something about that, > > >>>>> but for 7.8, where win64 is in preview, I think it's likely to > > >>>>> remain and we'll sort out the various possibilities with a bit > > >>>>> more time to > > consider. > > >>>>> > > >>>>> > > >>>>> On 11-02-20 6:36 AM, Steffen Märcker wrote: > > >>>>> > > >>>>>> I've just attempted to start the win64 vm on Windows 7 Prof. > > >>>>>> 64 Bit and got the message to install msvcr100.dll too. Do I > > >>>>>> understand this thread right that this is actually expected? > > >>>>>> > > >>>>>> Regards, Steffen > > >>>>>> > > >>>>>> > > >>>>>> Am 11.02.2011, 11:17 Uhr, schrieb Steven Kelly > > <[hidden email]>: > > >>>>>> > > >>>>>> > > >>>>>>> I just went through all VW monolithic VMs from 2.0 to 7.7.1 > > >>>>>>> with Dependency Walker: > > >>>>>>> > > >>>>>>> 2.0 and 2.5 statically linked any functions they called from > > >>>>>>> msvcrt.dll > > >>>>>>> > > >>>>>>> 3.0 dynamically linked msvcrt40.dll, but 3.0b already > > >>>>>>> changed that to just msvcrt.dll. > > >>>>>>> > > >>>>>>> 5i.3 - 7.7.1 have all dynamically linked msvcrt.dll, which > > >>>>>>> has been an obligatory part of standard Windows installs for > > >>>>>>> over a decade > > >>>>>>> > > <http://en.wikipedia.org/wiki/Microsoft_Windows_library_files#Ms > > >>>>>>> vcrt > > >>>>>>> .dll > > >>>>>>> > > >>>>>>>> (Windows 2000 on), in Windows\system32 (and before that > > >>>>>>>> part > > of > > >>>>>>>> a > > >>>>>>>> > > >>>>>>> normal Windows install since at least Windows 95 > > >>>>>>> <http://support.microsoft.com/kb/895959> ). > > >>>>>>> > > >>>>>>> > > >>>>>>> There's a big difference > > >>>>>>> <http://msdn.microsoft.com/en- > > >>>>>>> > > >>>> us/library/abx4dbyh(VS.71).aspx#CodeSp > > >>>> > > >>>>>>> ippe > > >>>>>>> t0> between msvcrt.dll (a system file) and msvcr[71-100].dll. > > >>>>>>> t0> The > > >>>>>>> former is guaranteed to be found (although you have no > > >>>>>>> control over the exact version), the latter must be > > >>>>>>> installed with your > > application. > > >>>>>>> > > >>>>>>> > > >>>>>>> In theory you shouldn't rely on the system msvcrt.dll, since > > >>>>>>> it will be a different version from what you used in your > > >>>>>>> own testing, but in practice for VW this seems to have worked well. > > >>>>>>> I imagine VW's reliance is pretty generic and stable, so > > >>>>>>> it's been more likely that things improved when MS shipped > > >>>>>>> an update to msvcrt.dll, than that things would break. XP > > >>>>>>> SP2 was the exception, as the significant changes it > > >>>>>>> introduced caused problems in many applications. It looks > > >>>>>>> like Microsoft are moving away from allowing 3rd party apps > > >>>>>>> to dynamically link to the system msvcrt.dll, so Cincom > > >>>>>>> should stop too. There's a good discussion > > >>>>>>> <http://stackoverflow.com/questions/1073509/should-i-redistr > > >>>>>>> ib > > >>>>>>> ut > > >>>>>>> e-ms > > >>>>>>> vcrt > > >>>>>>> -dll-with-my-application> on the pros and cons on > StackOverflow. > > >>>>>>> > > >>>>>>> > > >>>>>>> So, with the exception of 3.0 (which was corrected in 3.0b), > > >>>>>>> no previous VM has dynamically depended on a particular > > >>>>>>> msvcr[40-100].dll. Those particular DLLs aren't shipped with > > >>>>>>> Windows, and if you depend on them you MUST ship them. > > >>>>>>> > > >>>>>>> > > >>>>>>> Better though would be to statically link the CRT for the > > >>>>>>> 64-bit VM, using /MT. That would also seem to be good advice > > >>>>>>> for the 32-bit VM, to remove the dependency on the system > msvcrt.dll. > > >>>>>>> Statically linking the 64-bit VM will also significantly > > >>>>>>> reduce the total size of the application, since I imagine VW > > >>>>>>> only uses a tiny fraction of the whole msvcrt100.dll. > > >>>>>>> > > >>>>>>> > > >>>>>>> Cheers, > > >>>>>>> > > >>>>>>> Steve > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> From: [hidden email] [mailto:vw-dev- > > >>>>>>> > > >>>> [hidden email]] > > >>>> > > >>>>>>> On Behalf Of Alan Knight > > >>>>>>> Sent: 11. helmikuuta 2011 1:34 > > >>>>>>> To: [hidden email] > > >>>>>>> Subject: Re: vw7.8 64-bit on windows error > > >>>>>>> > > >>>>>>> > > >>>>>>> I don't think we have statically linked the MSVCR libraries > > >>>>>>> in previous versions, at least not for a very long time. I > > >>>>>>> also don't think that those libraries are part of the > > >>>>>>> Windows installs, but they tended to be there if you'd > > >>>>>>> installed anything at all. And possibly if the operating > > >>>>>>> system included programs that were built with those > > >>>>>>> compilers they would be for > > practical purposes included. > > >>>>>>> The difference in this case is, I suspect, that people have > > >>>>>>> fewer things installed that are 64-bit applications, and the > > >>>>>>> compiler > > is newer. > > >>>>>>> > > >>>>>>> It is not needed on 32-bit installations, because we are for > > >>>>>>> the moment still using an older compiler version for the > > >>>>>>> 32-bit versions, partly because of that dependency. Building > > >>>>>>> the 64-bit versions required the use of the more recent > > >>>>>>> compiler. 32-bit versions appear to my untrained eye to > > >>>>>>> require MSVCRT.DLL with no version number embedded in the > > >>>>>>> name. I don't believe it makes any > > >>>>>>> > > >>>> difference between visual.exe and vwnt.exe. > > >>>> > > >>>>>>> It's possible that we really ought to be installing it, but > > >>>>>>> it is not something we've ever done in the past and it does > > >>>>>>> not seem to have previously been an issue. > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> In earlier versions, the necessary parts of the MSVCR > > >>>>>>> library have been statically linked (IIRC), or then the > > >>>>>>> relevant library has been part of a normal Windows > > >>>>>>> installation anyway (maybe in IE?). Even the Cairo DLL was > > >>>>>>> kindly made by Travis to be statically linked rather than > > >>>>>>> require > > >>>>>>> MSCVR90.dll: > > >>>>>>> > > >>>>>>> http://www.parcplace.net/list/vwnc- > archive/0910/msg00085.html > > >>>>>>> > > >>>>>>> Information on static linking and msvcr100.dll is in the > > >>>>>>> last message > > >>>>>>> here: > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>> > > http://social.msdn.microsoft.com/Forums/en/vssetup/thread/6891665f- > > >>>> f > > >>>> > > >>>>>>> d83- > > >>>>>>> 426a-9d73-69d6d7e171a3 > > >>>>>>> > > >>>>>>> > > >>>>>>> As Martin said, a vendor using a redistributable dynamically > > >>>>>>> linked library like this is expected to ship it as part of > > >>>>>>> their installer > > >>>>>>> - as can be seen from e.g. InstallShield, which comes with a > > >>>>>>> wide range of redistributables that install builders can add > > >>>>>>> to their install. It's also what Microsoft says to do (IIUC): > > >>>>>>> > > >>>>>>> http://msdn.microsoft.com/en-us/library/ms235299.aspx > > >>>>>>> > > >>>>>>> "If you use a merge module that contains a Visual C++ DLL, > > >>>>>>> you must include it in the Windows Installer package (or > > >>>>>>> similar installation > > >>>>>>> package) that you are using to deploy the application" > > >>>>>>> > > >>>>>>> > > >>>>>>> Of course, all this is just for what Cincom should do when > > >>>>>>> providing their product, if that product were just an > > >>>>>>> application. Given the product in this case is a development > > >>>>>>> environment, Cincom should also provide automation and/or > > >>>>>>> instructions for developers to create and deploy their own > > >>>>>>> products - including any necessary > > >>>>>>> > > >>>> redistributables. > > >>>> > > >>>>>>> Otherwise end users are going to be reporting that the > > >>>>>>> application doesn't work, and developers aren't going to > > >>>>>>> understand why (and presumably Cincom isn't going to get any > > royalties in that case!). > > >>>>>>> > > >>>>>>> > > >>>>>>> Is msvcr100.dll also needed on 32-bit VW 7.8 installations > > >>>>>>> on > > Windows? > > >>>>>>> Does it make a difference if we use the monolithic > > >>>>>>> visual.exe VM or the split .exe+.dll VM? > > >>>>>>> > > >>>>>>> > > >>>>>>> Cheers, > > >>>>>>> > > >>>>>>> Steve > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> ________________________________ > > >>>>>>> > > >>>>>>> From: [hidden email] on behalf of Alan Knight > > >>>>>>> Sent: Thu 10/02/2011 19:55 > > >>>>>>> To: Martin McClure > > >>>>>>> Cc: [hidden email] > > >>>>>>> Subject: Re: vw7.8 64-bit on windows error > > >>>>>>> > > >>>>>>> > > >>>>>>> That isn't something we've done in the past. I think that > > >>>>>>> typically those libraries end up installed quite widely as > > >>>>>>> soon as you've installed anything. And it would be a bit > > >>>>>>> tricky, in that it wouldn't be integrated with our > > >>>>>>> installation > mechanisms. > > >>>>>>> I think about the best we could do at this point would be to > > >>>>>>> include a copy on the CD or download and people would have > > >>>>>>> to install it themselves. We can also look into trying to do > > >>>>>>> something in the next release when we expect to have Win64 > > >>>>>>> as fully supported, but it's quite > > >>>>>>> > > >>>> late to try much for this one. > > >>>> > > >>>>>>> On 2011-02-10 12:09 AM, Martin McClure wrote: > > >>>>>>> > > >>>>>>>> On 02/09/11 11:11, Alan Knight wrote: > > >>>>>>>> > > >>>>>>>>> you need to install the appropriate MS runtime for the > > >>>>>>>>> most recent compiler. > > >>>>>>>>> > > >>>>>>>> I'd gotten the impression that Microsoft's intent is that > > >>>>>>>> when an application requires a particular version of the > > >>>>>>>> MSVCR library, the application vendor should ship that > > >>>>>>>> MSVCR library along with the application. > > >>>>>>>> > > >>>>>>>> Would it be possible to include that with the Windows install? > > >>>>>>>> > > >>>>>>>> Regards, > > >>>>>>>> > > >>>>>>>> -Martin > > >>>>>>>> > > >>>>>>> -- > > >>>>>>> Alan Knight [|], Engineering Manager, Cincom Smalltalk > > >>>>>>> [hidden email] [hidden email] > > http://www.cincomsmalltalk.com > > >>>>>>> <http://www.cincomsmalltalk.com/> > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>> _______________________________________________ > > >>>> vwnc mailing list > > >>>> [hidden email] > > >>>> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > > >>>> > > >>>> > > >>> > > >>> > > >>> _______________________________________________ > > >>> vwnc mailing list > > >>> [hidden email] > > >>> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > > >>> > > >>> > > >>> > > >> > > >> > > > > > > _______________________________________________ > > > vwnc mailing list > > > [hidden email] > > > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > > > > _______________________________________________ > > vwnc mailing list > > [hidden email] > > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
«
Return to VisualWorks
|
1 view|%1 views
| Free forum by Nabble | Edit this page |