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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
40 messages Options
12
Reply | Threaded
Open this post in threaded view
|

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

mkobetic
"Terry Raymond"<[hidden email]> wrote:
> I guess I should ask, how badly broken is it? I am currently upgrading our
> application and we use SSL and HTTPS. I would really like to use 7.9 as it fixes
> several problems.

Depends on what you're talking about, VW or the Interwebs. These issues arose primarily because the new TLS supports more than just SSL 3.0 and there are servers and other networking hardware out there that don't handle these correctly. In some large scale tests the number of these broken endpoints was somewhere around 5%, and it should be improving as the web upgrades to better implementations, but it's still significant enough.

At this point the assumption is that the old SSL can handle more sites. That is largely because it simply avoids whole classes of problems by not supporting TLS, you can configure the new TLS stuff the same way as well (note that there are other less aggressive work-arounds which could be more suitable, e.g. some servers are willing to do newer protocol versions but are allergic to extensions, etc. this is all tunable with the TLS configuration). We hope to make some changes that may reduce the need for such drastic work-arounds. Some may actually belong to the higher level HTTPS frameworks rather than TLS, we'll see.

Note that dropping the protocol version is actually the primary "solution" to these problems that the web browsers employ as well. They try connecting with the best options, they fail, they analyze the error then dial back the protocol version and possibly other options and try again. They probably cache their previous results for specific websites as well. I'm not sure that we can be similarly aggressive with a general purpose TLS framework (maybe more so in the higher HTTPS layers)

That said, we certainly can allow for more protocol lenient configurations and such. There were still other cases that we do not understand yet. One of those, that Boris pointed out, was www.buydomains.com, which started working since then, but presumably there will be others like that. Ultimately it boils down to what Boris alluded to. You need to try the sites you need to reach and see. In most cases they should work fine. If they don't then there's the question of what's broken, Boris' links discuss several of these scenarios. Note that it can be quite difficult to figure it out and may requires substantial knowledge of the protocol, I'd suggest simply pointing such site out in this list here or to our support and we'll take a look at what's going on. There are different ways to work around these cases by configuring our TLS end differently to avoid the issue.

In short, there likely are changes we can make to make VW more resilient when interacting with these (arguably broken) implementations, but calling our TLS broken because of this doesn't paint entirely accurate picture.

Martin

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


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

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

Holger Kleinsorgen
In reply to this post by Christian Haider
Christian Haider wrote
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?
Done, but visual.exe crashes immediately on startup ;) I have no clue why.  vwnt.exe doesn't but it does require vwntoe.dll, of course.

But why exactly do you need a single executable? That means that you can never use Cairo, Pango, Database client libraries etc.
Even portable applications usually have multiple files. Some are even distributed as an installer that installs a portable app (ok, I hate that;)
Reply | Threaded
Open this post in threaded view
|

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

Andres Valloud-6
In reply to this post by Steven Kelly
Hello...

We know having a single executable deployment option on Windows is
important to at least some of you.  At the same time, we have Microsoft
saying what all of us should do is to install the redistributable
library or some such.  I note that I have seen Windows Updates that
specifically update this redistributable in e.g. our build machines, and
this is consistent with Microsoft's advice.

So, what should we do?... there are several points of view on this
matter, unfortunately they do not all agree, and they have their pros
and cons.  Here are a few of the issues we're currently pondering.  We
hope you will excuse any inaccuracies or perhaps less than polished
phrasing.  The necessary research is not done yet.  We want good answers
to these and other similar questions, and getting to a thorough
understanding will take time.  We will get to it, please be patient with us.

a.  Previous to the last compiler upgrade, we were not linking the CRT
statically to the VMs.  Linking statically is against the current,
recommended official Microsoft procedure.  We could do it, but should
we?  If we run into problems, then likely Microsoft's response could be
that what we chose to do is unsupported.  Then what?

b.  If we statically link the CRT to the VMs, then Windows Updates do
not apply to the VMs.  But we should still supply reasonably updated
VMs.  Exactly how many versions of the VMs are we supposed to produce
and support?  In other words, what subset of the Cartessian product
between "Microsoft patch levels" and "supported VM versions" do we care
about?  And exactly how do we set that up?

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?

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.  Unsurprisingly, this results in
spectacular failures.  You can see this by running the DLLCC tests that
use cptst.dll.  Wouldn't we set ourselves up for more of the same by
linking the CRT statically?

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?

Andres & Pete.


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
>

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

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

Christian Haider
In reply to this post by Christian Haider
Holger Kleinsorgen wrote
> Christian Haider wrote
> >
> > 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?
> >
> Done, but visual.exe crashes immediately on startup ;) I have no clue
why.
> vwnt.exe doesn't but it does require vwntoe.dll, of course.

:-(
 
> But why exactly do you need a single executable? That means that you
can
> never use Cairo, Pango, Database client libraries etc.
> Even portable applications usually have multiple files. Some are even
> distributed as an installer that installs a portable app (ok, I hate
that;)

I like single executables because it make things simpler for the user
(and for me). My motto is "Make it easy" and this approach fits well
with it:
- the user has to deal with only one file
- admins like to have it on a file server for users to start
- easy to use several versions (f.ex. for testing): just rename the file
and it will not interfere with other versions

And yes, the restrictions apply.
Luckily, I don't do any database work - and if, I would know the client
is installed and I could bind dynamically to it.

Lacking good modern graphics is indeed painful - this is my core
business, after all.
With Cairo I have mixed feelings. Generally, I think it is a good thing,
but
- the main reason for Cairo is platform independence, which I don't need
since I am bound to Windows (until Bloomberg ports its terminal to the
Mac).
- Cairo does not add much to what Windows already has (i.e. dynamically
linkable DLLs which are guaranteed to be installed), actually, I
understand that Cairo-on-windows is merely a compatibility layer
delegating to the native window stuff.
- Since I have my own PostScript and PDF rendering, I don't need Cairo
for that. It would only be useful for screen rendering, but I feel that
I can do that easier directly with win32.
- Cairo and Pango more so, seem to be hard to configure and seem to be
very version sensitive (of what I see on the mailing lists).
- After many years Cincom still has not decided on a strategy for
graphics and fonts. Cairo is still not supported from Cincom and now,
since Travis, the principal force behind it, has left Cincom, it is not
clear to me how the story will continue.

Please excuse my side ranting about graphics (well, you asked :-) ), but
for my kind of application (light weight specific client app) the single
executable is a very attractive deployment option.

Cheers,
        Christian

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

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

Holger Kleinsorgen
Christian Haider wrote
- the user has to deal with only one file
- admins like to have it on a file server for users to start
- easy to use several versions (f.ex. for testing): just rename the file
and it will not interfere with other versions
You can put your deployed executables with runtime libraries on a file server and run it from there. We have a lot of customers that do that. For instance, we've included the WinGDI DLL in the past. No installer involved.

The customers can also put several versions on the file server (e.g. versions for testing). The different versions dont need different versions of MSVCRT and other external libraries, so that's not a problem.
You can also add library version checks. For instance, we check the VM version so accidentaly running a vwnt-based application with the wrong vwntoe.dll is not possible.
Reply | Threaded
Open this post in threaded view
|

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

Maarten Mostert
In reply to this post by Christian Haider

Hi,

Making an NSIS installer is a pain for a couple of hours, but after that it is really easy to install, remove update etc etc. Allthough I envisage to go the Reinhout way to be more MSI and W8 in the future.

Cairo is not just about multiplatform ! You will write notably less code because of its API and we all know how much code you need to write nice graphics.

I agree however that Cairo still has issues, only sometimes I manage to take an image with open Cairo graphics from platform to platform. It might be that I do things wrong somewhere, and Itherefore I would really appreciate if the Cairo stuff would finally be intergated (like Skins) into the IDE. It would force the dev team to solve all these.

 

@+Maarten,

 

 

-----Original Message-----
From: "Christian Haider" <[hidden email]>
Sent: Thursday, 19 July, 2012 09:40
To: "Holger Kleinsorgen" <[hidden email]>, [hidden email]
Subject: Re: [vwnc] [now vw7.9] msvcr100.dll Re: vw7.8 64-bit on windowserror

Holger Kleinsorgen wrote
> Christian Haider wrote
> >
> > 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?
> >
> Done, but visual.exe crashes immediately on startup ;) I have no clue
why.
> vwnt.exe doesn't but it does require vwntoe.dll, of course.

:-(

> But why exactly do you need a single executable? That means that you
can
> never use Cairo, Pango, Database client libraries etc.
> Even portable applications usually have multiple files. Some are even
> distributed as an installer that installs a portable app (ok, I hate
that;)

I like single executables because it make things simpler for the user
(and for me). My motto is "Make it easy" and this approach fits well
with it:
- the user has to deal with only one file
- admins like to have it on a file server for users to start
- easy to use several versions (f.ex. for testing): just rename the file
and it will not interfere with other versions

And yes, the restrictions apply.
Luckily, I don't do any database work - and if, I would know the client
is installed and I could bind dynamically to it.

Lacking good modern graphics is indeed painful - this is my core
business, after all.
With Cairo I have mixed feelings. Generally, I think it is a good thing,
but
- the main reason for Cairo is platform independence, which I don't need
since I am bound to Windows (until Bloomberg ports its terminal to the
Mac).
- Cairo does not add much to what Windows already has (i.e. dynamically
linkable DLLs which are guaranteed to be installed), actually, I
understand that Cairo-on-windows is merely a compatibility layer
delegating to the native window stuff.
- Since I have my own PostScript and PDF rendering, I don't need Cairo
for that. It would only be useful for screen rendering, but I feel that
I can do that easier directly with win32.
- Cairo and Pango more so, seem to be hard to configure and seem to be
very version sensitive (of what I see on the mailing lists).
- After many years Cincom still has not decided on a strategy for
graphics and fonts. Cairo is still not supported from Cincom and now,
since Travis, the principal force behind it, has left Cincom, it is not
clear to me how the story will continue.

Please excuse my side ranting about graphics (well, you asked :-) ), but
for my kind of application (light weight specific client app) the single
executable is a very attractive deployment option.

Cheers,
Christian

_______________________________________________
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
Reply | Threaded
Open this post in threaded view
|

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

Christian Haider
In reply to this post by Christian Haider
Yes this is all possible, but it does not feel right.
The extra file(s) are completely private to the application, yet I would
have to force the user to deal with it: (s)he has to know that this file
must be close to the executable and must not be forgotten or messed
with.
This is junk knowledge and I am always annoyed when I have to learn
things for an app where the only interest in it is to make that app
run...
My users are no IT guys: graphic designers, journalists or data wizards.
They are especially reluctant to get into IT details just for making one
of the programs run with which they have to do their job.

All of that is not really a big deal. Just as I said - it was very
convenient the way it was, that's all.
But, of course, I hope that Cincom will make this possible in the future
again.

Christian

Holger Kleinsorgen wrote
> Christian Haider wrote
> >
> > - the user has to deal with only one file
> > - admins like to have it on a file server for users to start
> > - easy to use several versions (f.ex. for testing): just rename the
> > file and it will not interfere with other versions
> >
>
> You can put your deployed executables with runtime libraries on a file
server
> and run it from there. We have a lot of customers that do that. For
instance,
> we've included the WinGDI DLL in the past. No installer involved.
>
> The customers can also put several versions on the file server (e.g.
> versions for testing). The different versions dont need different
versions of
> MSVCRT and other external libraries, so that's not a problem.
> You can also add library version checks. For instance, we check the VM
> version so accidentaly running a vwnt-based application with the wrong
> vwntoe.dll is not possible.
>
> --
> View this message in context:
http://forum.world.st/now-vw7-9-msvcr100-
> dll-Re-vw7-8-64-bit-on-windows-error-tp4640037p4640663.html
> Sent from the VisualWorks mailing list archive at Nabble.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
Reply | Threaded
Open this post in threaded view
|

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

Steven Kelly
In reply to this post by Andres Valloud-6
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. 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 :).

> a.  Previous to the last compiler upgrade, we were not linking the CRT
> statically to the VMs.  Linking statically is against the current,
> recommended official Microsoft procedure.  We could do it, but should
> we?  If we run into problems, then likely Microsoft's response could be
> that what we chose to do is unsupported.  Then what?

IIUC static linking is supported. It's not their first choice, but that's a different thing.

> b.  If we statically link the CRT to the VMs, then Windows Updates do
> not apply to the VMs.  

Also if you place the CRT in the VW directory, Windows Updates do not apply to it. Windows Updates only apply if VW or some other app has separately installed the redistributable. I don't know the prevalence of the redistributable, but it's certainly not common enough to rely on.

> But we should still supply reasonably updated
> VMs.  Exactly how many versions of the VMs are we supposed to produce
> and support?  In other words, what subset of the Cartessian product
> between "Microsoft patch levels" and "supported VM versions" do we care
> about?  And exactly how do we set that up?

Hmm. VW isn't exactly proactive in updating to the latest versions of Cairo or zlib :), so I don't think this is a real problem. I'd be happy if you updated to the latest stable version each time you release an official VM.

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.

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

Microsoft has built SxS to allow precisely this: multiple applications using multiple versions of the same DLL on the same PC at the same time. And that's with the recommended strategy of redistributables - it's always been possible with installation alongside or static linking. 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.

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

Cairo works just fine with the 7.7.1 visual.exe, as do other DLLs I've used.

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.

All the best,
Steve

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


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

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

Andres Valloud-6
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.
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

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

Steven Kelly
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.

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

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

Christian Haider
In reply to this post by Andres Valloud-6
+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.
>


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

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

Dave & Vicki Stevenson
Thinking out loud with a poor understanding of the issues is a good way to sound the fool; but I guess I'm used to that, so here goes:
 
I believe with Vista and later (I've only got XP here at work) Windoze exploder has zip integrated to the point that one can expand a .zip file like a folder, copy things in and out, and I think even run zipped executables.
 
Is it feasible to leverage this paradigm to define some kind of archive that appears to Windows as executable, such that attempting to execute it 'autoplays' one of the executable files it contains? And allow said executable to link to libraries in the archive (for example, if the desired library were not found elsewhere in the PATH)? And allow the executable to 'auto-update' libraries or files in the archive, for example downloaded patches?
 
Such a mechanism would yield the best of both 'single file deployment' and 'linkable libraries' worlds, but would not help to keep the deliverable small.
 
Dave Stevenson
[hidden email]
 

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

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

Andres Valloud-6
In reply to this post by Christian Haider
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.
>>
>
>
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

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

Christian Haider
In reply to this post by Christian Haider
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?

Christian

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


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

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

Steven Kelly
In reply to this post by Andres Valloud-6
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)?

Thanks,
Steve

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

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

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

Andres Valloud-6
In reply to this post by Christian Haider
(I snipped some of this email, it's getting big again)

On 8/22/2012 12:02 AM, Christian Haider wrote:

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

Some users may find value in simply following Microsoft's CRT updates
instead of having to produce a new VM to statically link the latest CRT
library patches.  I'd imagine there may be users for which security
considerations are much more important.  I am not a lawyer, but I'm
thinking specifically about regulated industries in which even the
appearance of negligence implies significant liabilities.

Andres.
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

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

Andres Valloud-6
In reply to this post by Steven Kelly
Hello,

On 8/22/2012 3:37 AM, Steven Kelly wrote:

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

Basically we have no control over applications that may explicitly or
implicitly e.g. call malloc() with one CRT and then free() with another
CRT.  There is some amount of risk in providing statically linked VMs
only.  We cannot really perform an exhaustive code audit of every app to
make sure statically linked VMs will not run into problems with any
existing code out there.  It's an unknown amount of risk though.  Maybe
the preferable course of action is to fix the code that runs into
trouble thus making it more robust...

... so we need feedback from our users on this matter :).

Andres.
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

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

Eliot Miranda-2
In reply to this post by Andres Valloud-6
Hi Andres,

On Tue, Aug 21, 2012 at 6:49 PM, Andres Valloud <[hidden email]> wrote:
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.

Have you tested access to errno from a dynamically-loaded dll that is dynamically linked against msvcrtXX.dll?   IIRC my reason for using dynamic linking is that in this case the VM sees the errno inside the static C rtl but the dll sees the errno in msvcrtXX.dll.  They may have fixed this now and made errno a thread-local variable, but it used to be the case that the C rtl and the C dll had separate errno's.


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.
>>
>
>
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc



--
best,
Eliot


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

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

Andres Valloud-6
Eliot, what is your use case?  What would you expect to happen, and why?

On 8/23/2012 12:05 PM, Eliot Miranda wrote:
> Have you tested access to errno from a dynamically-loaded dll that
> is dynamically linked against msvcrtXX.dll?   IIRC my reason for
> using dynamic linking is that in this case the VM sees the errno
> inside the static C rtl but the dll sees the errno in msvcrtXX.dll.
> They may have fixed this now and made errno a thread-local variable,
> but it used to be the case that the C rtl and the C dll had separate
> errno's.
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

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

Eliot Miranda-2


On Fri, Jan 25, 2013 at 1:09 AM, Andres Valloud <[hidden email]> wrote:
Eliot, what is your use case?  What would you expect to happen, and why?

Use of a third-party library that returns extended error information in errno.  I expect VisualWorks to see the same errno variable as the library loaded.  VisualWorks needs to access the relevant errno so as to allow harvesting of the extended error information.

On 8/23/2012 12:05 PM, Eliot Miranda wrote:
Have you tested access to errno from a dynamically-loaded dll that
is dynamically linked against msvcrtXX.dll?   IIRC my reason for
using dynamic linking is that in this case the VM sees the errno
inside the static C rtl but the dll sees the errno in msvcrtXX.dll.
They may have fixed this now and made errno a thread-local variable,
but it used to be the case that the C rtl and the C dll had separate
errno's.
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc



--
best,
Eliot

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
12