[now vw7.9] msvcr100.dll Re: vw7.8 64-bit on windows error

>
> 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

> 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
>>>
>>>>>>>

>>>>>>>> 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
>>>>>>>>
>>>>>>>>
>>>>>>>>

>>>>>
>>>>>
>>>>>>>> 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
>

> c.  Let's say we link statically against version X of the CRT library.
> Now you load another library that calls a dependency on version Y of
> the
> CRT library.  Will multiple versions of the CRT be loaded at the same
> time?  What happens if e.g. our VM does a malloc() with version X, then
> the pointer is passed to the external library, and then the external
> library does a free() of that pointer with version Y of the CRT?  What
> if it's something a bit more involved than malloc() / free()?  Does it
> make sense to have multiple uncoordinated versions of the CRT loaded at
> the same time?

> On 7/16/2012 1:46 AM, Steven Kelly wrote:
> > 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
> >

> -----Original Message-----
> From: Andres Valloud [mailto:[hidden email]]
> Sent: 19. heinäkuuta 2012 13:20
> To: Steven Kelly
> Cc: Christian Haider; Niall Ross; [hidden email];
> [hidden email]; VWNC List
> Subject: Re: [vwnc] [now vw7.9] msvcr100.dll Re: vw7.8 64-bit onwindows
> error
>
> Hello, I have some clarifications here... also I'll snip some of the
> quoted text, this email is getting large :).  Now, with that said,
> please note we're not done with our homework yet, so we're not ready to
> make any claims at this point :).
>
> On 7/19/2012 2:28 AM, Steven Kelly wrote:
> > Thanks Andres, good to hear your thoughts on this. You're asking
> > valid questions and raising valid concerns, and I hope I can set your
> > mind at rest with valid answers. I think at the end of the day the
> > fear is about there being multiple versions of something. That,
> > unfortunately, is not under our control, and none of the ways of
> > referencing the CRT removes that problem.
>
> That's what I've been seeing so far in my investigation... using
> depends.exe on something like UxTheme.dll can be sobering...
>
> > However, static linking may
> > reduce our exposure to the problem. Of course, just saying to
> > customers "VW needs the CRT", and leaving it to them to figure out
> > the details, would best reduce _Cincom's_ initial exposure to the
> > problem, but I don't think that's your plan or the best long term
> > solution :).
>
> We need to collect more information before we can formulate a plan, and
> we're not there yet :).
>
> > IIUC static linking is supported. It's not their first choice, but
> > that's a different thing.
>
> I'd be inclined to agree with you at this point.  There are caveats
> regarding cross CRT communication though, if we went this route then we
> would have to make clear (e.g. document) there are implications outside
> of our control.
>
> > Hmm. VW isn't exactly proactive in updating to the latest versions of
> > Cairo or zlib :),
>
> Yeah, I noticed earlier that they do not seem to be compiled with the
> same compiler that was used to make the VMs... hmmm...
>
> > I'd be happy if you updated to the latest stable version each time
> you
> > release an official VM.
>
> Ok, this is helpful to know.  Thank you :).  If any others have
> thoughts
> on this, we would really like to hear from you.
>
> > Note that this isn't a static linking issue: you will always have
> > this problem, as long as VW uses CRT. It doesn't matter if you
> > recommend a redistributable, installing the CRT alongside VW, or
> > static linking. You have to provide us with the right CRT version, or
> > at least tell us what versions you support. It's not the linking with
> > /MT that takes time, it's the testing and deciding on the supported
> > version(s), and that you can't avoid.
>
> That testing part is still unaddressed in our discussions, at least as
> far as coming to a consensus on what constitutes proper testing.
>
> > Of course whenever there are multiple
> > versions of something, there will be questions about compatibility,
> > but malloc/free doesn't sound like a serious example - why would the
> > second library be freeing a pointer from the first library?
>
> > You can't escape the fact that there are multiple versions of the
> > CRT. If you don't statically link, you are just more exposed to those
> > risks - you don't know which version you are calling even in the
> > simplest case.
>
> Well, malloc / free is an example on MSDN's own docs.  For example,
>
> http://msdn.microsoft.com/en-us/library/ms235460.aspx
>
> Even though malloc / free can be a problem on its own, I think it's
> just
> a representative of a family of problems.  To be more specific, the
> link
> above starts by saying that you might run into trouble if you e.g.
> create a handle via DLLCC and then pass that handle to the VM so the VM
> does something with it.  Or if you pass a DLLCC some handle the VM
> created.
>
> >> d.  We provide vwnt.exe and vwntoe.dll because of linkage
> >> problems. For example, if you are using visual.exe and you try
> >> looking for some function in vwntoe.dll (which is contained by
> >> visual.exe), then vwntoe.dll is loaded anyway and now you have two
> >> uncoordinated copies of the VM running at the same time.
> >
> > Why would anyone do this? I thought the functions in vwntoe.dll were
> > all in visual.exe, and in both cases are accessed from an
> > ExternalInterface class without explicitly mentioning the library.
>
> That is something that, at least on my part, needs more thought and
> consideration.  I do know there are non trivial reasons why this is a
> problem, I'm not that familiar with them at this time.
>
> >> e.  The above seems to suggest we should at least carefully
> >> consider the usefulness and limitations of visual.exe.  How does
> >> that play with other external libraries we ship ourselves, e.g.
> >> Cairo?
> >
> > Nooo! Please don't drop visual.exe. VW already makes us work hard
> > enough in the deployment phase, please don't make it harder.
>
> Nono, hold on there :)... what I wrote should be read more literally.
> Let me rephrase: in the context of static linking, we need to be able
> to
> explain exactly why visual.exe is useful and why it could be limited.
> For example, what would we have to do in terms of documentation (in
> particular, I had Appendix D of the DLLCC manual in mind)?  What would
> we have to do provide customers so that the choices and their
> implications are clear?
>
> I think in the above I sort of assumed that visual.exe would be linked
> statically, as opposed to dynamically, but right now we do not see it
> has to be the case either... we're not in the decision business yet.
>
> > Of course I understand your pain with the large number of different
> > VMs. If it's any help, I only really use two: visual.exe for
> > development and deployment, and the debug VM for the rare times when
> > I'm helping you debug a VM problem.
>
> Our point of view also includes the issue of support... should we
> decide
> to produce statically linked VMs, do we understand the implications
> enough such that we can be reasonably sure you guys won't run into
> critical unsolvable issues that immediately defeat our goals?  If we
> decide to do something else, is it going to work?
>
> To summarize, right now we're looking into things and getting a better
> understanding of the issues involved.  Basically, our concern is with
> how the unknowns due to changing how the VM has been historically
> compiled could affect you.  We won't make any decisions until we feel
> comfortable with our understanding.  With that in mind, if you have
> feedback for us, please let us know right away.  We are more likely to
> reach a better outcome if we include more information in the process.
> We thank you in advance for your patience while we perform our due
> diligence.
>
> Andres.

> -----Ursprüngliche Nachricht-----
> Von: Steven Kelly [mailto:[hidden email]]
> Gesendet: Donnerstag, 19. Juli 2012 12:46
> An: Andres Valloud
> Cc: Christian Haider; Niall Ross; [hidden email];
> [hidden email]; VWNC List
> Betreff: RE: [vwnc] [now vw7.9] msvcr100.dll Re: vw7.8 64-bit onwindows
> error
>
> Many, many thanks Andres! An absolute model of an answer, and I'm happy
> with everything you say. Thanks for the clarifications, and all the best as you
> do the hard work of finding all the ramifications of the various alternatives.
>
> Steve
>
> > -----Original Message-----
> > From: Andres Valloud [mailto:[hidden email]]
> > Sent: 19. heinäkuuta 2012 13:20
> > To: Steven Kelly
> > Cc: Christian Haider; Niall Ross; [hidden email];
> > [hidden email]; VWNC List
> > Subject: Re: [vwnc] [now vw7.9] msvcr100.dll Re: vw7.8 64-bit
> > onwindows error
> >
> > Hello, I have some clarifications here... also I'll snip some of the
> > quoted text, this email is getting large :).  Now, with that said,
> > please note we're not done with our homework yet, so we're not ready
> > to make any claims at this point :).
> >
> > On 7/19/2012 2:28 AM, Steven Kelly wrote:
> > > Thanks Andres, good to hear your thoughts on this. You're asking
> > > valid questions and raising valid concerns, and I hope I can set
> > > your mind at rest with valid answers. I think at the end of the day
> > > the fear is about there being multiple versions of something. That,
> > > unfortunately, is not under our control, and none of the ways of
> > > referencing the CRT removes that problem.
> >
> > That's what I've been seeing so far in my investigation... using
> > depends.exe on something like UxTheme.dll can be sobering...
> >
> > > However, static linking may
> > > reduce our exposure to the problem. Of course, just saying to
> > > customers "VW needs the CRT", and leaving it to them to figure out
> > > the details, would best reduce _Cincom's_ initial exposure to the
> > > problem, but I don't think that's your plan or the best long term
> > > solution :).
> >
> > We need to collect more information before we can formulate a plan,
> > and we're not there yet :).
> >
> > > IIUC static linking is supported. It's not their first choice, but
> > > that's a different thing.
> >
> > I'd be inclined to agree with you at this point.  There are caveats
> > regarding cross CRT communication though, if we went this route then
> > we would have to make clear (e.g. document) there are implications
> > outside of our control.
> >
> > > Hmm. VW isn't exactly proactive in updating to the latest versions
> > > of Cairo or zlib :),
> >
> > Yeah, I noticed earlier that they do not seem to be compiled with the
> > same compiler that was used to make the VMs... hmmm...
> >
> > > I'd be happy if you updated to the latest stable version each time
> > you
> > > release an official VM.
> >
> > Ok, this is helpful to know.  Thank you :).  If any others have
> > thoughts on this, we would really like to hear from you.
> >
> > > Note that this isn't a static linking issue: you will always have
> > > this problem, as long as VW uses CRT. It doesn't matter if you
> > > recommend a redistributable, installing the CRT alongside VW, or
> > > static linking. You have to provide us with the right CRT version,
> > > or at least tell us what versions you support. It's not the linking
> > > with /MT that takes time, it's the testing and deciding on the
> > > supported version(s), and that you can't avoid.
> >
> > That testing part is still unaddressed in our discussions, at least as
> > far as coming to a consensus on what constitutes proper testing.
> >
> > > Of course whenever there are multiple versions of something, there
> > > will be questions about compatibility, but malloc/free doesn't sound
> > > like a serious example - why would the second library be freeing a
> > > pointer from the first library?
> >
> > > You can't escape the fact that there are multiple versions of the
> > > CRT. If you don't statically link, you are just more exposed to
> > > those risks - you don't know which version you are calling even in
> > > the simplest case.
> >
> > Well, malloc / free is an example on MSDN's own docs.  For example,
> >
> > http://msdn.microsoft.com/en-us/library/ms235460.aspx
> >
> > Even though malloc / free can be a problem on its own, I think it's
> > just a representative of a family of problems.  To be more specific,
> > the link above starts by saying that you might run into trouble if you
> > e.g.
> > create a handle via DLLCC and then pass that handle to the VM so the
> > VM does something with it.  Or if you pass a DLLCC some handle the VM
> > created.
> >
> > >> d.  We provide vwnt.exe and vwntoe.dll because of linkage problems.
> > >> For example, if you are using visual.exe and you try looking for
> > >> some function in vwntoe.dll (which is contained by visual.exe),
> > >> then vwntoe.dll is loaded anyway and now you have two uncoordinated
> > >> copies of the VM running at the same time.
> > >
> > > Why would anyone do this? I thought the functions in vwntoe.dll were
> > > all in visual.exe, and in both cases are accessed from an
> > > ExternalInterface class without explicitly mentioning the library.
> >
> > That is something that, at least on my part, needs more thought and
> > consideration.  I do know there are non trivial reasons why this is a
> > problem, I'm not that familiar with them at this time.
> >
> > >> e.  The above seems to suggest we should at least carefully
> > >> consider the usefulness and limitations of visual.exe.  How does
> > >> that play with other external libraries we ship ourselves, e.g.
> > >> Cairo?
> > >
> > > Nooo! Please don't drop visual.exe. VW already makes us work hard
> > > enough in the deployment phase, please don't make it harder.
> >
> > Nono, hold on there :)... what I wrote should be read more literally.
> > Let me rephrase: in the context of static linking, we need to be able
> > to explain exactly why visual.exe is useful and why it could be
> > limited.
> > For example, what would we have to do in terms of documentation (in
> > particular, I had Appendix D of the DLLCC manual in mind)?  What would
> > we have to do provide customers so that the choices and their
> > implications are clear?
> >
> > I think in the above I sort of assumed that visual.exe would be linked
> > statically, as opposed to dynamically, but right now we do not see it
> > has to be the case either... we're not in the decision business yet.
> >
> > > Of course I understand your pain with the large number of different
> > > VMs. If it's any help, I only really use two: visual.exe for
> > > development and deployment, and the debug VM for the rare times
> when
> > > I'm helping you debug a VM problem.
> >
> > Our point of view also includes the issue of support... should we
> > decide to produce statically linked VMs, do we understand the
> > implications enough such that we can be reasonably sure you guys won't
> > run into critical unsolvable issues that immediately defeat our goals?
> > If we decide to do something else, is it going to work?
> >
> > To summarize, right now we're looking into things and getting a better
> > understanding of the issues involved.  Basically, our concern is with
> > how the unknowns due to changing how the VM has been historically
> > compiled could affect you.  We won't make any decisions until we feel
> > comfortable with our understanding.  With that in mind, if you have
> > feedback for us, please let us know right away.  We are more likely to
> > reach a better outcome if we include more information in the process.
> > We thank you in advance for your patience while we perform our due
> > diligence.
> >
> > Andres.
>

> +1
> Also, thank you Steven for sharing your technical insights and asking the right constructive questions!
>
> Andres, my hope is on you :-)
>
>
>> -----Ursprüngliche Nachricht-----
>> Von: Steven Kelly [mailto:[hidden email]]
>> Gesendet: Donnerstag, 19. Juli 2012 12:46
>> An: Andres Valloud
>> Cc: Christian Haider; Niall Ross; [hidden email];
>> [hidden email]; VWNC List
>> Betreff: RE: [vwnc] [now vw7.9] msvcr100.dll Re: vw7.8 64-bit onwindows
>> error
>>
>> Many, many thanks Andres! An absolute model of an answer, and I'm happy
>> with everything you say. Thanks for the clarifications, and all the best as you
>> do the hard work of finding all the ramifications of the various alternatives.
>>
>> Steve
>>
>>> -----Original Message-----
>>> From: Andres Valloud [mailto:[hidden email]]
>>> Sent: 19. heinäkuuta 2012 13:20
>>> To: Steven Kelly
>>> Cc: Christian Haider; Niall Ross; [hidden email];
>>> [hidden email]; VWNC List
>>> Subject: Re: [vwnc] [now vw7.9] msvcr100.dll Re: vw7.8 64-bit
>>> onwindows error
>>>
>>> Hello, I have some clarifications here... also I'll snip some of the
>>> quoted text, this email is getting large :).  Now, with that said,
>>> please note we're not done with our homework yet, so we're not ready
>>> to make any claims at this point :).
>>>
>>> On 7/19/2012 2:28 AM, Steven Kelly wrote:
>>>> Thanks Andres, good to hear your thoughts on this. You're asking
>>>> valid questions and raising valid concerns, and I hope I can set
>>>> your mind at rest with valid answers. I think at the end of the day
>>>> the fear is about there being multiple versions of something. That,
>>>> unfortunately, is not under our control, and none of the ways of
>>>> referencing the CRT removes that problem.
>>>
>>> That's what I've been seeing so far in my investigation... using
>>> depends.exe on something like UxTheme.dll can be sobering...
>>>
>>>> However, static linking may
>>>> reduce our exposure to the problem. Of course, just saying to
>>>> customers "VW needs the CRT", and leaving it to them to figure out
>>>> the details, would best reduce _Cincom's_ initial exposure to the
>>>> problem, but I don't think that's your plan or the best long term
>>>> solution :).
>>>
>>> We need to collect more information before we can formulate a plan,
>>> and we're not there yet :).
>>>
>>>> IIUC static linking is supported. It's not their first choice, but
>>>> that's a different thing.
>>>
>>> I'd be inclined to agree with you at this point.  There are caveats
>>> regarding cross CRT communication though, if we went this route then
>>> we would have to make clear (e.g. document) there are implications
>>> outside of our control.
>>>
>>>> Hmm. VW isn't exactly proactive in updating to the latest versions
>>>> of Cairo or zlib :),
>>>
>>> Yeah, I noticed earlier that they do not seem to be compiled with the
>>> same compiler that was used to make the VMs... hmmm...
>>>
>>>> I'd be happy if you updated to the latest stable version each time
>>> you
>>>> release an official VM.
>>>
>>> Ok, this is helpful to know.  Thank you :).  If any others have
>>> thoughts on this, we would really like to hear from you.
>>>
>>>> Note that this isn't a static linking issue: you will always have
>>>> this problem, as long as VW uses CRT. It doesn't matter if you
>>>> recommend a redistributable, installing the CRT alongside VW, or
>>>> static linking. You have to provide us with the right CRT version,
>>>> or at least tell us what versions you support. It's not the linking
>>>> with /MT that takes time, it's the testing and deciding on the
>>>> supported version(s), and that you can't avoid.
>>>
>>> That testing part is still unaddressed in our discussions, at least as
>>> far as coming to a consensus on what constitutes proper testing.
>>>
>>>> Of course whenever there are multiple versions of something, there
>>>> will be questions about compatibility, but malloc/free doesn't sound
>>>> like a serious example - why would the second library be freeing a
>>>> pointer from the first library?
>>>
>>>> You can't escape the fact that there are multiple versions of the
>>>> CRT. If you don't statically link, you are just more exposed to
>>>> those risks - you don't know which version you are calling even in
>>>> the simplest case.
>>>
>>> Well, malloc / free is an example on MSDN's own docs.  For example,
>>>
>>> http://msdn.microsoft.com/en-us/library/ms235460.aspx
>>>
>>> Even though malloc / free can be a problem on its own, I think it's
>>> just a representative of a family of problems.  To be more specific,
>>> the link above starts by saying that you might run into trouble if you
>>> e.g.
>>> create a handle via DLLCC and then pass that handle to the VM so the
>>> VM does something with it.  Or if you pass a DLLCC some handle the VM
>>> created.
>>>
>>>>> d.  We provide vwnt.exe and vwntoe.dll because of linkage problems.
>>>>> For example, if you are using visual.exe and you try looking for
>>>>> some function in vwntoe.dll (which is contained by visual.exe),
>>>>> then vwntoe.dll is loaded anyway and now you have two uncoordinated
>>>>> copies of the VM running at the same time.
>>>>
>>>> Why would anyone do this? I thought the functions in vwntoe.dll were
>>>> all in visual.exe, and in both cases are accessed from an
>>>> ExternalInterface class without explicitly mentioning the library.
>>>
>>> That is something that, at least on my part, needs more thought and
>>> consideration.  I do know there are non trivial reasons why this is a
>>> problem, I'm not that familiar with them at this time.
>>>
>>>>> e.  The above seems to suggest we should at least carefully
>>>>> consider the usefulness and limitations of visual.exe.  How does
>>>>> that play with other external libraries we ship ourselves, e.g.
>>>>> Cairo?
>>>>
>>>> Nooo! Please don't drop visual.exe. VW already makes us work hard
>>>> enough in the deployment phase, please don't make it harder.
>>>
>>> Nono, hold on there :)... what I wrote should be read more literally.
>>> Let me rephrase: in the context of static linking, we need to be able
>>> to explain exactly why visual.exe is useful and why it could be
>>> limited.
>>> For example, what would we have to do in terms of documentation (in
>>> particular, I had Appendix D of the DLLCC manual in mind)?  What would
>>> we have to do provide customers so that the choices and their
>>> implications are clear?
>>>
>>> I think in the above I sort of assumed that visual.exe would be linked
>>> statically, as opposed to dynamically, but right now we do not see it
>>> has to be the case either... we're not in the decision business yet.
>>>
>>>> Of course I understand your pain with the large number of different
>>>> VMs. If it's any help, I only really use two: visual.exe for
>>>> development and deployment, and the debug VM for the rare times
>> when
>>>> I'm helping you debug a VM problem.
>>>
>>> Our point of view also includes the issue of support... should we
>>> decide to produce statically linked VMs, do we understand the
>>> implications enough such that we can be reasonably sure you guys won't
>>> run into critical unsolvable issues that immediately defeat our goals?
>>> If we decide to do something else, is it going to work?
>>>
>>> To summarize, right now we're looking into things and getting a better
>>> understanding of the issues involved.  Basically, our concern is with
>>> how the unknowns due to changing how the VM has been historically
>>> compiled could affect you.  We won't make any decisions until we feel
>>> comfortable with our understanding.  With that in mind, if you have
>>> feedback for us, please let us know right away.  We are more likely to
>>> reach a better outcome if we include more information in the process.
>>> We thank you in advance for your patience while we perform our due
>>> diligence.
>>>
>>> Andres.
>>
>
>

> -----Ursprüngliche Nachricht-----
> Von: [hidden email] [mailto:[hidden email]]
> Im Auftrag von Andres Valloud
> Gesendet: Mittwoch, 22. August 2012 05:01
> An: Christian Haider
> Cc: Steven Kelly; Niall Ross; [hidden email]; [hidden email];
> VWNC List; VWDEV list
> Betreff: Re: AW: [vwnc] [now vw7.9] msvcr100.dll Re: vw7.8 64-bit
> onwindows error
>
>
> Here you have an update on the statically vs dynamically linked Windows
> VMs.  We finished a bunch of thorough testing, and so far we can't see any
> difference between statically and dynamically linked VMs.  Since July, we also
> deleted about 1650 LOC of makefiles, which facilitates making further
> changes.  So, statically linked VMs are a real option for us now.
>
> So now, exactly how are we going to do this?  Here are a couple options.
>
> 1.  Make every executable we ship statically linked and be done with it.
>   This gives us less VMs to compile, and also allows us to proceed without
> creating two whole new platforms (win-static vs win-dynamic, 32 and 64 bits
> each).  We would need different platform ids because it must be possible to
> tell which VM is which.
>
> 2.  But the above defeats the idea of installing the redistributable CRT and
> getting updates from Microsoft, so we could ship two sets of 32 and
> 64 bit Windows VMs.  Also, unlike the statically linked VMs, there may be
> some scenarios in which the dynamically linked VMs are preferable
> particularly in the presence of third party DLLs that also link dynamically to
> (basically) the same CRT.
>
> Feedback, please :).
>
> Andres.
>
> On 7/19/2012 4:14 AM, Christian Haider wrote:
> > +1
> > Also, thank you Steven for sharing your technical insights and asking the
> right constructive questions!
> >
> > Andres, my hope is on you :-)
> >
> >
> >> -----Ursprüngliche Nachricht-----
> >> Von: Steven Kelly [mailto:[hidden email]]
> >> Gesendet: Donnerstag, 19. Juli 2012 12:46
> >> An: Andres Valloud
> >> Cc: Christian Haider; Niall Ross; [hidden email];
> >> [hidden email]; VWNC List
> >> Betreff: RE: [vwnc] [now vw7.9] msvcr100.dll Re: vw7.8 64-bit
> >> onwindows error
> >>
> >> Many, many thanks Andres! An absolute model of an answer, and I'm
> >> happy with everything you say. Thanks for the clarifications, and all
> >> the best as you do the hard work of finding all the ramifications of the
> various alternatives.
> >>
> >> Steve
> >>
> >>> -----Original Message-----
> >>> From: Andres Valloud [mailto:[hidden email]]
> >>> Sent: 19. heinäkuuta 2012 13:20
> >>> To: Steven Kelly
> >>> Cc: Christian Haider; Niall Ross; [hidden email];
> >>> [hidden email]; VWNC List
> >>> Subject: Re: [vwnc] [now vw7.9] msvcr100.dll Re: vw7.8 64-bit
> >>> onwindows error
> >>>
> >>> Hello, I have some clarifications here... also I'll snip some of the
> >>> quoted text, this email is getting large :).  Now, with that said,
> >>> please note we're not done with our homework yet, so we're not ready
> >>> to make any claims at this point :).
> >>>
> >>> On 7/19/2012 2:28 AM, Steven Kelly wrote:
> >>>> Thanks Andres, good to hear your thoughts on this. You're asking
> >>>> valid questions and raising valid concerns, and I hope I can set
> >>>> your mind at rest with valid answers. I think at the end of the day
> >>>> the fear is about there being multiple versions of something. That,
> >>>> unfortunately, is not under our control, and none of the ways of
> >>>> referencing the CRT removes that problem.
> >>>
> >>> That's what I've been seeing so far in my investigation... using
> >>> depends.exe on something like UxTheme.dll can be sobering...
> >>>
> >>>> However, static linking may
> >>>> reduce our exposure to the problem. Of course, just saying to
> >>>> customers "VW needs the CRT", and leaving it to them to figure out
> >>>> the details, would best reduce _Cincom's_ initial exposure to the
> >>>> problem, but I don't think that's your plan or the best long term
> >>>> solution :).
> >>>
> >>> We need to collect more information before we can formulate a plan,
> >>> and we're not there yet :).
> >>>
> >>>> IIUC static linking is supported. It's not their first choice, but
> >>>> that's a different thing.
> >>>
> >>> I'd be inclined to agree with you at this point.  There are caveats
> >>> regarding cross CRT communication though, if we went this route then
> >>> we would have to make clear (e.g. document) there are implications
> >>> outside of our control.
> >>>
> >>>> Hmm. VW isn't exactly proactive in updating to the latest versions
> >>>> of Cairo or zlib :),
> >>>
> >>> Yeah, I noticed earlier that they do not seem to be compiled with
> >>> the same compiler that was used to make the VMs... hmmm...
> >>>
> >>>> I'd be happy if you updated to the latest stable version each time
> >>> you
> >>>> release an official VM.
> >>>
> >>> Ok, this is helpful to know.  Thank you :).  If any others have
> >>> thoughts on this, we would really like to hear from you.
> >>>
> >>>> Note that this isn't a static linking issue: you will always have
> >>>> this problem, as long as VW uses CRT. It doesn't matter if you
> >>>> recommend a redistributable, installing the CRT alongside VW, or
> >>>> static linking. You have to provide us with the right CRT version,
> >>>> or at least tell us what versions you support. It's not the linking
> >>>> with /MT that takes time, it's the testing and deciding on the
> >>>> supported version(s), and that you can't avoid.
> >>>
> >>> That testing part is still unaddressed in our discussions, at least
> >>> as far as coming to a consensus on what constitutes proper testing.
> >>>
> >>>> Of course whenever there are multiple versions of something, there
> >>>> will be questions about compatibility, but malloc/free doesn't
> >>>> sound like a serious example - why would the second library be
> >>>> freeing a pointer from the first library?
> >>>
> >>>> You can't escape the fact that there are multiple versions of the
> >>>> CRT. If you don't statically link, you are just more exposed to
> >>>> those risks - you don't know which version you are calling even in
> >>>> the simplest case.
> >>>
> >>> Well, malloc / free is an example on MSDN's own docs.  For example,
> >>>
> >>> http://msdn.microsoft.com/en-us/library/ms235460.aspx
> >>>
> >>> Even though malloc / free can be a problem on its own, I think it's
> >>> just a representative of a family of problems.  To be more specific,
> >>> the link above starts by saying that you might run into trouble if
> >>> you e.g.
> >>> create a handle via DLLCC and then pass that handle to the VM so the
> >>> VM does something with it.  Or if you pass a DLLCC some handle the
> >>> VM created.
> >>>
> >>>>> d.  We provide vwnt.exe and vwntoe.dll because of linkage problems.
> >>>>> For example, if you are using visual.exe and you try looking for
> >>>>> some function in vwntoe.dll (which is contained by visual.exe),
> >>>>> then vwntoe.dll is loaded anyway and now you have two
> >>>>> uncoordinated copies of the VM running at the same time.
> >>>>
> >>>> Why would anyone do this? I thought the functions in vwntoe.dll
> >>>> were all in visual.exe, and in both cases are accessed from an
> >>>> ExternalInterface class without explicitly mentioning the library.
> >>>
> >>> That is something that, at least on my part, needs more thought and
> >>> consideration.  I do know there are non trivial reasons why this is
> >>> a problem, I'm not that familiar with them at this time.
> >>>
> >>>>> e.  The above seems to suggest we should at least carefully
> >>>>> consider the usefulness and limitations of visual.exe.  How does
> >>>>> that play with other external libraries we ship ourselves, e.g.
> >>>>> Cairo?
> >>>>
> >>>> Nooo! Please don't drop visual.exe. VW already makes us work hard
> >>>> enough in the deployment phase, please don't make it harder.
> >>>
> >>> Nono, hold on there :)... what I wrote should be read more literally.
> >>> Let me rephrase: in the context of static linking, we need to be
> >>> able to explain exactly why visual.exe is useful and why it could be
> >>> limited.
> >>> For example, what would we have to do in terms of documentation (in
> >>> particular, I had Appendix D of the DLLCC manual in mind)?  What
> >>> would we have to do provide customers so that the choices and their
> >>> implications are clear?
> >>>
> >>> I think in the above I sort of assumed that visual.exe would be
> >>> linked statically, as opposed to dynamically, but right now we do
> >>> not see it has to be the case either... we're not in the decision business
> yet.
> >>>
> >>>> Of course I understand your pain with the large number of different
> >>>> VMs. If it's any help, I only really use two: visual.exe for
> >>>> development and deployment, and the debug VM for the rare times
> >> when
> >>>> I'm helping you debug a VM problem.
> >>>
> >>> Our point of view also includes the issue of support... should we
> >>> decide to produce statically linked VMs, do we understand the
> >>> implications enough such that we can be reasonably sure you guys
> >>> won't run into critical unsolvable issues that immediately defeat our
> goals?
> >>> If we decide to do something else, is it going to work?
> >>>
> >>> To summarize, right now we're looking into things and getting a
> >>> better understanding of the issues involved.  Basically, our concern
> >>> is with how the unknowns due to changing how the VM has been
> >>> historically compiled could affect you.  We won't make any decisions
> >>> until we feel comfortable with our understanding.  With that in
> >>> mind, if you have feedback for us, please let us know right away.
> >>> We are more likely to reach a better outcome if we include more
> information in the process.
> >>> We thank you in advance for your patience while we perform our due
> >>> diligence.
> >>>
> >>> Andres.
> >>
> >
> >
>

> On 7/19/2012 4:14 AM, Christian Haider wrote:
> > +1
> > Also, thank you Steven for sharing your technical insights and asking
> the right constructive questions!
> >
> > Andres, my hope is on you :-)
> >
> >
> >> -----Ursprüngliche Nachricht-----
> >> Von: Steven Kelly [mailto:[hidden email]]
> >> Gesendet: Donnerstag, 19. Juli 2012 12:46
> >> An: Andres Valloud
> >> Cc: Christian Haider; Niall Ross; [hidden email];
> >> [hidden email]; VWNC List
> >> Betreff: RE: [vwnc] [now vw7.9] msvcr100.dll Re: vw7.8 64-bit
> onwindows
> >> error
> >>
> >> Many, many thanks Andres! An absolute model of an answer, and I'm
> happy
> >> with everything you say. Thanks for the clarifications, and all the
> best as you
> >> do the hard work of finding all the ramifications of the various
> alternatives.
> >>
> >> Steve
> >>
> >>> -----Original Message-----
> >>> From: Andres Valloud [mailto:[hidden email]]
> >>> Sent: 19. heinäkuuta 2012 13:20
> >>> To: Steven Kelly
> >>> Cc: Christian Haider; Niall Ross; [hidden email];
> >>> [hidden email]; VWNC List
> >>> Subject: Re: [vwnc] [now vw7.9] msvcr100.dll Re: vw7.8 64-bit
> >>> onwindows error
> >>>
> >>> Hello, I have some clarifications here... also I'll snip some of
> the
> >>> quoted text, this email is getting large :).  Now, with that said,
> >>> please note we're not done with our homework yet, so we're not
> ready
> >>> to make any claims at this point :).
> >>>
> >>> On 7/19/2012 2:28 AM, Steven Kelly wrote:
> >>>> Thanks Andres, good to hear your thoughts on this. You're asking
> >>>> valid questions and raising valid concerns, and I hope I can set
> >>>> your mind at rest with valid answers. I think at the end of the
> day
> >>>> the fear is about there being multiple versions of something. That,
> >>>> unfortunately, is not under our control, and none of the ways of
> >>>> referencing the CRT removes that problem.
> >>>
> >>> That's what I've been seeing so far in my investigation... using
> >>> depends.exe on something like UxTheme.dll can be sobering...
> >>>
> >>>> However, static linking may
> >>>> reduce our exposure to the problem. Of course, just saying to
> >>>> customers "VW needs the CRT", and leaving it to them to figure out
> >>>> the details, would best reduce _Cincom's_ initial exposure to the
> >>>> problem, but I don't think that's your plan or the best long term
> >>>> solution :).
> >>>
> >>> We need to collect more information before we can formulate a plan,
> >>> and we're not there yet :).
> >>>
> >>>> IIUC static linking is supported. It's not their first choice, but
> >>>> that's a different thing.
> >>>
> >>> I'd be inclined to agree with you at this point.  There are caveats
> >>> regarding cross CRT communication though, if we went this route
> then
> >>> we would have to make clear (e.g. document) there are implications
> >>> outside of our control.
> >>>
> >>>> Hmm. VW isn't exactly proactive in updating to the latest versions
> >>>> of Cairo or zlib :),
> >>>
> >>> Yeah, I noticed earlier that they do not seem to be compiled with
> the
> >>> same compiler that was used to make the VMs... hmmm...
> >>>
> >>>> I'd be happy if you updated to the latest stable version each time
> >>> you
> >>>> release an official VM.
> >>>
> >>> Ok, this is helpful to know.  Thank you :).  If any others have
> >>> thoughts on this, we would really like to hear from you.
> >>>
> >>>> Note that this isn't a static linking issue: you will always have
> >>>> this problem, as long as VW uses CRT. It doesn't matter if you
> >>>> recommend a redistributable, installing the CRT alongside VW, or
> >>>> static linking. You have to provide us with the right CRT version,
> >>>> or at least tell us what versions you support. It's not the
> linking
> >>>> with /MT that takes time, it's the testing and deciding on the
> >>>> supported version(s), and that you can't avoid.
> >>>
> >>> That testing part is still unaddressed in our discussions, at least
> as
> >>> far as coming to a consensus on what constitutes proper testing.
> >>>
> >>>> Of course whenever there are multiple versions of something, there
> >>>> will be questions about compatibility, but malloc/free doesn't
> sound
> >>>> like a serious example - why would the second library be freeing a
> >>>> pointer from the first library?
> >>>
> >>>> You can't escape the fact that there are multiple versions of the
> >>>> CRT. If you don't statically link, you are just more exposed to
> >>>> those risks - you don't know which version you are calling even in
> >>>> the simplest case.
> >>>
> >>> Well, malloc / free is an example on MSDN's own docs.  For example,
> >>>
> >>> http://msdn.microsoft.com/en-us/library/ms235460.aspx
> >>>
> >>> Even though malloc / free can be a problem on its own, I think it's
> >>> just a representative of a family of problems.  To be more specific,
> >>> the link above starts by saying that you might run into trouble if
> you
> >>> e.g.
> >>> create a handle via DLLCC and then pass that handle to the VM so
> the
> >>> VM does something with it.  Or if you pass a DLLCC some handle the
> VM
> >>> created.
> >>>
> >>>>> d.  We provide vwnt.exe and vwntoe.dll because of linkage
> problems.
> >>>>> For example, if you are using visual.exe and you try looking for
> >>>>> some function in vwntoe.dll (which is contained by visual.exe),
> >>>>> then vwntoe.dll is loaded anyway and now you have two
> uncoordinated
> >>>>> copies of the VM running at the same time.
> >>>>
> >>>> Why would anyone do this? I thought the functions in vwntoe.dll
> were
> >>>> all in visual.exe, and in both cases are accessed from an
> >>>> ExternalInterface class without explicitly mentioning the library.
> >>>
> >>> That is something that, at least on my part, needs more thought and
> >>> consideration.  I do know there are non trivial reasons why this is
> a
> >>> problem, I'm not that familiar with them at this time.
> >>>
> >>>>> e.  The above seems to suggest we should at least carefully
> >>>>> consider the usefulness and limitations of visual.exe.  How does
> >>>>> that play with other external libraries we ship ourselves, e.g.
> >>>>> Cairo?
> >>>>
> >>>> Nooo! Please don't drop visual.exe. VW already makes us work hard
> >>>> enough in the deployment phase, please don't make it harder.
> >>>
> >>> Nono, hold on there :)... what I wrote should be read more
> literally.
> >>> Let me rephrase: in the context of static linking, we need to be
> able
> >>> to explain exactly why visual.exe is useful and why it could be
> >>> limited.
> >>> For example, what would we have to do in terms of documentation (in
> >>> particular, I had Appendix D of the DLLCC manual in mind)?  What
> would
> >>> we have to do provide customers so that the choices and their
> >>> implications are clear?
> >>>
> >>> I think in the above I sort of assumed that visual.exe would be
> linked
> >>> statically, as opposed to dynamically, but right now we do not see
> it
> >>> has to be the case either... we're not in the decision business yet.
> >>>
> >>>> Of course I understand your pain with the large number of
> different
> >>>> VMs. If it's any help, I only really use two: visual.exe for
> >>>> development and deployment, and the debug VM for the rare times
> >> when
> >>>> I'm helping you debug a VM problem.
> >>>
> >>> Our point of view also includes the issue of support... should we
> >>> decide to produce statically linked VMs, do we understand the
> >>> implications enough such that we can be reasonably sure you guys
> won't
> >>> run into critical unsolvable issues that immediately defeat our
> goals?
> >>> If we decide to do something else, is it going to work?
> >>>
> >>> To summarize, right now we're looking into things and getting a
> better
> >>> understanding of the issues involved.  Basically, our concern is
> with
> >>> how the unknowns due to changing how the VM has been historically
> >>> compiled could affect you.  We won't make any decisions until we
> feel
> >>> comfortable with our understanding.  With that in mind, if you have
> >>> feedback for us, please let us know right away.  We are more likely
> to
> >>> reach a better outcome if we include more information in the
> process.
> >>> We thank you in advance for your patience while we perform our due
> >>> diligence.
> >>>
> >>> Andres.
> >>
> >
> >

> Great news!
>
> I would be very happy with the statically linked versions.
>
> I think that *my application* has no issues with outdated CRT
> libraries since my users cannot change fonts, display their own
> pictures or access arbitrary web contents. All resources are
> contained in the app so that I cannot foresee any problems with maybe
> discovered security holes in the CRT.
>
> What would be the reasons for linking the lib dynamically and,
> therefore, profiting from updates?

> Many thanks to Andres and others for their work on this!
>
> On 22.8.2012 4:49, Andres Valloud [[hidden email]] wrote:
>> We finished a bunch of thorough testing, and so far we can't see
>> any difference between statically and dynamically linked VMs.
>> Statically linked VMs are a real option for us now.
>>
>> 1.  Make every executable we ship statically linked and be done
>> with it.
>
> Yes!
>
>> there may be some scenarios in which the dynamically linked VMs are
>> preferable particularly in the presence of third party DLLs that
>> also link dynamically to (basically) the same CRT.
>
> It would be great if you could give more detail about this: what kind
> of scenarios, what kind of problems. Does it affect the Cairo DLLs?
> What about new ExternalInterface classes that use the DLLs that are
> now statically linked (e.g. calling extra Windows system functions)?