Jump to content











Photo
- - - - -

Microsoft Visual C++ Runtime


  • Please log in to reply
38 replies to this topic

#1 homes32

homes32

    Gold Member

  • .script developer
  • 1021 posts
  • Location:Minnesota
  •  
    United States

Posted 31 August 2011 - 02:21 PM

Posted Image

File Name: Microsoft Visual C++ Runtime
File Submitter: homes32
File Submitted: 31 Aug 2011
File Updated: 22 Nov 2013
File Category: System scripts

Allows you to run programs created with Microsoft Visual C++ 2005/2008/2010/2012

This script supports both 32 and 64 bit versions of Vista, Win7 and Win8 based projects.

Big Thanks to ChrisR and JFX for all the help, improvements, and testing!

Click here to download this file
  • ludovici likes this

#2 ludovici

ludovici

    Silver Member

  • .script developer
  • 610 posts
  • Location:France
  •  
    France

Posted 31 August 2011 - 03:02 PM

Your download link don't work :dubbio:

#3 FerrariGuy

FerrariGuy

    Member

  • Members
  • 50 posts
  • Location:South Carolina
  •  
    United States

Posted 31 August 2011 - 03:10 PM

Your download link don't work :dubbio:


Ditto. The link is currently pointing to http://homes32.winbu...net/scripts.php Looking forward to using the updated script. Thanks!

#4 homes32

homes32

    Gold Member

  • .script developer
  • 1021 posts
  • Location:Minnesota
  •  
    United States

Posted 31 August 2011 - 03:13 PM

Your download link don't work :dubbio:

the download portal is not behaving :(
http://reboot.pro/15...post__p__136616

and i haven't had a chance to get a mirror up yet...stay tuned.

Edit: Mirror should be working now.

#5 sbaeder

sbaeder

    Gold Member

  • .script developer
  • 1334 posts
  • Location:usa - massachusettes
  •  
    United States

Posted 31 August 2011 - 05:05 PM

p.s. a better name might include the word "runtime" or "Redistributable Runtrime"... But a good addition!

#6 homes32

homes32

    Gold Member

  • .script developer
  • 1021 posts
  • Location:Minnesota
  •  
    United States

Posted 31 August 2011 - 05:47 PM

p.s. a better name might include the word "runtime" or "Redistributable Runtrime"... But a good addition!

fixed. it was suppose to say runtime...don't know why it didn't.

#7 ChrisR

ChrisR

    Silver Member

  • .script developer
  • 784 posts
  •  
    France

Posted 01 September 2011 - 08:07 AM

Thank you :thumbsup: .

A nice rewrite of JFX VCruntime script, with the addition of Visual C++ 2010.

Is it not good to keep the checkbox "Add native x64 VC++ Runtime libarys to x64 builds" to reduce the size of building, if native x64 not needed ?

#8 homes32

homes32

    Gold Member

  • .script developer
  • 1021 posts
  • Location:Minnesota
  •  
    United States

Posted 06 September 2011 - 02:08 PM

Is it not good to keep the checkbox "Add native x64 VC++ Runtime libarys to x64 builds" to reduce the size of building, if native x64 not needed ?

in most of the x64 apps I have tested native x64 run-time is needed, mostly because a lot of apps still use a hybrid approach where some components are x64 and some are x86. (even if the app says its x64 release) general users can't be expected to know the difference so the decision was made on the basis of simplicity and low script overhead. feel free to try and change my mind though if you think this is an essential feature.

#9 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 13331 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 06 September 2011 - 02:52 PM

in most of the x64 apps I have tested native x64 run-time is needed, mostly because a lot of apps still use a hybrid approach where some components are x64 and some are x86. (even if the app says its x64 release) general users can't be expected to know the difference so the decision was made on the basis of simplicity and low script overhead. feel free to try and change my mind though if you think this is an essential feature.


I am not sure I'm getting this right, but as I see it:
  • IF I build a 32-bit I want NO x64 thingies
  • IF I build a 64-bit I may want x32 ALSO
So, if a 32 bit build is chosen no x64 files should be included, EVER, but if a 64 bit build is chosen there could be a checkbox, checked by default to the effect of:

I am adding also some 32bit files that are often needed, uncheck this ONLY if you know what you are doing


:cheers:
Wonko

#10 homes32

homes32

    Gold Member

  • .script developer
  • 1021 posts
  • Location:Minnesota
  •  
    United States

Posted 06 September 2011 - 03:05 PM

right. if your source is 32bit no x64 files are included.
if your source is x64 both native x64 and WOW64 32bit

I am adding also some 32bit files that are often needed, uncheck this ONLY if you know what you are doing

and since when as that stopped anyone? :)

anyway the true question here is:
Is it truly necessary for this option to be there or is it mostly useless and confusing?
for reference the x86 runtimes add ~30MB to the final build.


EDIT:
just for clarification
Wonko's is suggesting a checkbox for excluding 32bit runtime components from x64 builds
ChrisR is suggesting that x64 components are never included (even with a x64 source) unless a checkbox is ticked.

#11 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 13331 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 06 September 2011 - 03:20 PM

and since when as that stopped anyone? :)

The idea is NOT stopping people from doing stupid things (as that is impossible), only to let them know that what they are going to do is probably stupid, final goal being to reduce the amount of whining :ph34r: around.


30 Mb is what I call a very interesting size for a WHOLE OS/PE environment. ;) but I completely fail to see anyway the actual *need* of a 64-bit PE :( , so my personal opionion is worthless in this case.

:cheers:
Wonko

#12 homes32

homes32

    Gold Member

  • .script developer
  • 1021 posts
  • Location:Minnesota
  •  
    United States

Posted 06 September 2011 - 03:28 PM

The idea is NOT stopping people from doing stupid things (as that is impossible), only to let them know that what they are going to do is probably stupid, final goal being to reduce the amount of whining :ph34r: around.

and when has warning the user that they are about to do something stupid ever reduced the amount of whining when they do it anyway? :buehehe:

your comments have been useful though. if an option where to be made available it would make more sense to go the route you suggested and provide a method to exclude 32bit files from an x64 build rather then exclude x64 files from a x64 build.

I will wait to hear from others to see if this is truly a useful option or unneeded "bloat"

#13 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 13331 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 06 September 2011 - 03:52 PM

and when has warning the user that they are about to do something stupid ever reduced the amount of whining when they do it anyway? :buehehe:


Let's say that it has a limited effect :(, on the other hand my ideal approach (much more effective in practice) is NOT a viable solution with current hardware:
http://reboot.pro/12494/page__st__40
http://www.msfn.org/.../page__st__1142
http://reboot.pro/8480/page__st__305

your comments have been useful though. if an option where to be made available it would make more sense to go the route you suggested and provide a method to exclude 32bit files from an x64 build rather then exclude x64 files from a x64 build.

Happy it was at least partially useful, now I can give you a way to make it even more complex :ph34r::
Why do I have to get the VC 2005, 2008 and 2010 runtimes in one single "block"? :dubbio:

I mean the idea of "componentizing" a build should be that of having it reduced to a number of the smallest elemments and then find a way to re-group these elements in easier to select "blocks".
The granularity of such blocks should IMHO (and in theory, I am trying to convince people about this since a number of years with NO practical result :frusty:) be multi-level, allowing both the "newbie" (select level 1) and the extremely advanced user (select sublevel 4 Item 1 only) the wider (and wilder) possibilities....

:cheers:
Wonko

#14 MedEvil

MedEvil

    Platinum Member

  • .script developer
  • 7771 posts

Posted 06 September 2011 - 04:22 PM

I mean the idea of "componentizing" a build should be that of having it reduced to a number of the smallest elemments and then find a way to re-group these elements in easier to select 'blocks'.
The granularity of such blocks should IMHO (and in theory, I am trying to convince people about this since a number of years with NO practical result :frusty: be multi-level, allowing both the 'newbie' (select level 1) and the extremely advanced user (select sublevel 4 Item 1 only) the wider (and wilder) possibilities....

Can you give an example, how this should work?


:cheers:

PS: There is only one way to stop users from whining. Shoot them! :lol:

#15 homes32

homes32

    Gold Member

  • .script developer
  • 1021 posts
  • Location:Minnesota
  •  
    United States

Posted 06 September 2011 - 04:27 PM

Why do I have to get the VC 2005, 2008 and 2010 runtimes in one single "block"? :dubbio:

I mean the idea of "componentizing" a build should be that of having it reduced to a number of the smallest elemments and then find a way to re-group these elements in easier to select "blocks".
The granularity of such blocks should IMHO (and in theory, I am trying to convince people about this since a number of years with NO practical result :frusty:) be multi-level, allowing both the "newbie" (select level 1) and the extremely advanced user (select sublevel 4 Item 1 only) the wider (and wilder) possibilities....

:cheers:
Wonko


well I don't think the idea of "componentizing" really applys to programming runtimes...
I really don't expect average users to know (or care) what runtime the application they are using requires...when the app is installed in "real" windows the installer generally takes care of making sure everything is in order and the required runtimes are present. The user generally doesn't know if the program is written in delphi, VB6, C++/C, COBOL, etc or what runtime files are needed.
with pe there is no installer to check and make sure the program as the proper operating environment, unless you want each script to include its own routines for installing the runtimes, possibly being buggy and deleting/overwriting other working entries and increasing the size of app scripts and overall build processing time.
that being said, there are checkboxes on the script interface to disable individual runtimes you don't need if you are still stuck on CD-Rs and need the extra couple of MB...
so in this case it seems more logical to enable the runtimes be default and let advanced users turn them off.


PS: I find the idea of the aggressive user interface highly amusing...

#16 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 13331 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 06 September 2011 - 06:26 PM

It was not actually aimed at the VC components (so it is OT :ph34r:) the thing that I dream (and I have talked about it at length with Medevil in the past, the one he originally suggested for - in his usual collaborative approach - Windows XP embedded, which is IMHO one of the most failed attempt of producing anything actually useful) .
http://reboot.pro/2690/page__st__18
Later he changed his mind apparently:
http://reboot.pro/3422/page__st__20
http://reboot.pro/3465/

As I see it the fact is that there is should be no need for the VC components .script selection at all accessible to the "common" final user.
  • In a perfect world we would know which exact files and Registry entries are needed as "side dish" to *any* "main" app, and the "main" app .script should be:
  • independent
  • have documented (and human readable dependencies) of *any* kind
  • have a "direct" access to "side-dish" .scripts (like these VC runtimes) and auto include them if needed (and if not already included by a previously processed .script) and autoinclude ONLY the part hat is strictly needed

Please note how this would also solve some of the problems Medevil is currently whining :ph34r: about:
http://reboot.pro/15385/

As often happens when Wonko (the Sane) and Medevil agree on something :) they get to the same thing through different paths, the real problem is, as ALWAYS happens, that noone else ever contributes and some ideas, though promising, never make progresses :(.


:cheers:
Wonko

#17 MedEvil

MedEvil

    Platinum Member

  • .script developer
  • 7771 posts

Posted 06 September 2011 - 07:04 PM

Ahh, that's what you were refering to. Still a great idea for a PE, no matter the source.

But i'm still stuck with the stupid registry.
Havn't found any way to tell valid keys, from broken ones, from missing ones, from unneeded ones.

:cheers:

#18 homes32

homes32

    Gold Member

  • .script developer
  • 1021 posts
  • Location:Minnesota
  •  
    United States

Posted 06 September 2011 - 07:08 PM


As I see it the fact is that there is should be no need for the VC components .script selection at all accessible to the "common" final user.

  • In a perfect world we would know which exact files and Registry entries are needed as "side dish" to *any* "main" app, and the "main" app .script should be:
  • independent
  • have documented (and human readable dependencies) of *any* kind
  • have a "direct" access to "side-dish" .scripts (like these VC runtimes) and auto include them if needed (and if not already included by a previously processed .script) and autoinclude ONLY the part hat is strictly needed

agreed. I have this partially implemented with my Avira and Wireshark scripts. but to avoid users whining about scripts altering their build and overriding their scripts you actually have to press the button to autodownload the runtime and enable it.

#19 MedEvil

MedEvil

    Platinum Member

  • .script developer
  • 7771 posts

Posted 06 September 2011 - 07:38 PM

@Wonko
To crosslink another topic in here.

One thing, that was clear from the start was, that creating a registry database is a huge task, even with a feasible plan.
It would require a lot of people to chip in. I do not see, that we even have enough developers left, much less, ones willing to put their life on hold for a while to do just this.

So unless you have a bunch of IT-slaves, that you can donate to the cause.
This database would definitly have to be pay - or donation ware these days.


:cheers:

#20 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 13331 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 07 September 2011 - 09:58 AM

@Wonko
To crosslink another topic in here.

One thing, that was clear from the start was, that creating a registry database is a huge task, even with a feasible plan.
It would require a lot of people to chip in. I do not see, that we even have enough developers left, much less, ones willing to put their life on hold for a while to do just this.

So unless you have a bunch of IT-slaves, that you can donate to the cause.
This database would definitly have to be pay - or donation ware these days.

You are right (partially), but actually if some "real programmer" (one of those that drink coke) would be willing to work on it, it is not really-really that big an ordeal.
Once we find a smart way to store the data (and that it is easy to access, human readable, and what not) my idea would be to post process or re-parse existing Winbuilder projects and .scripts.
Let's say a "different" Winbuilder engine that instead of really building something, it simply creates the database with the info in .scripts.
If we give this database (that will need of course manual intervention and correction fixes) to the .script developers AND *somehow* we make the use of this database more convenient when writing .scripts than manually adding dependency lines in .scripts and re-inventing wheels at every new .script, the database may enter a "virtuous circle". :dubbio:
As I see it we already have a big amount of information available, only we don't know how to use it properly (in the sense of using it to the aim of easening life of .script developers and simplify/standardise .script generation and projects).



:cheers:
Wonko

#21 MedEvil

MedEvil

    Platinum Member

  • .script developer
  • 7771 posts

Posted 07 September 2011 - 01:14 PM

Hmm, for the first time, i think that we might not have talked about the same thing in the past.

I was always talking about creating a dependable, verifyable database.

What you suggest, is a database which is neighter dependable nor verifyable. It's just the usual cobbled together data in another format.

Since the days of BartPE, plugin and script names imply an order, which just does not exist!
It is very common, that not everything needed for modul A, is in a script named modul A. Very often there are bits and pieces also in plugins and scripts, with names, that suggest, that they have absolutely nothing to do with modul A.

I wouldn't waste any time on a project like you suggest. But if you're interested, reading some strings from a script and writing them into some human readable output file, isn't complicated, you could do it in batch.

:cheers:

#22 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 13331 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 07 September 2011 - 01:55 PM

What you suggest, is a database which is neighter dependable nor verifyable. It's just the usual cobbled together data in another format.

Since the days of BartPE, plugin and script names imply an order, which just does not exist!
It is very common, that not everything needed for modul A, is in a script named modul A. Very often there are bits and pieces also in plugins and scripts, with names, that suggest, that they have absolutely nothing to do with modul A.

I wouldn't waste any time on a project like you suggest. But if you're interested, reading some strings from a script and writing them into some human readable output file, isn't complicated, you could do it in batch.


Actually you seemingly wouldn't waste *any* time with anything, but that's allright. :)

The issue is not "extracting" the data, it is to "catalog" them and store them in an easily accessible format that can be used to "rebuild" .scripts from the actual database.
Of course some work has to be done with the data, but it is not like re-running dependency walker on every single little app (like if we were starting from ground up).
We have a number of .scripts actually working (though as you pointed out often implemented "badly").

Let's see if I can make an example of the idea (which again I have not been able to find a way to implement).
You have a .script for app "A".
You try it on the LEAST (most minimal you can have) build.
It either works (and then ALL needed dependencies are inside the .script) <- the data you can get from it is OK as is. (it is possible that in the .script there are MORE things than barely needed, but this would be IMHO mostly an exception)
or it doesn't, in which case you put it aside for the moment.
You get another .script and loop through the above, etc.
With a relative simple chore that needs not any particular waste of time and that most members could do (I am thinking of something like a "frozen" project that could run, say, in Qemu) we have a database of "independent" .scripts and one of "not-independent ones".
Then we could tackle one by one the "bad-guys", I am pretty sure that we will soon find "patterns", i.e. "habits" typical of the .script developer or of the Program Author, that may easen fixing the other .scripts from the same developer or the .scripts for other programs by the same Author.

I am not talking of blindly importing all .scripts in the database, I am rather suggesting to find a way to not let the work already done go waste and restart from 0.

If you prefer I am not suggesting that it will be a trifling matter, only that it could be less gargantuan than you seem to think.

:cheers:
Wonko

#23 MedEvil

MedEvil

    Platinum Member

  • .script developer
  • 7771 posts

Posted 07 September 2011 - 02:34 PM

The two problems i see with you idea are:

1.) You start out from an unreliable source. So the result will be unreliable. (garbage in - garbage out)

2.) Your proposed methode, works, if at all, only for app scripts and tweaks. One can't simply remove a base script from the build for a test. So it can never be tested, if a dependency of script X, is actually in one of the base scripts, where it doesn't belong.
So we're back at point 1.) gi-go.


What i just don't understand is, where you see the benefit of having the content of the scripts in a human readable database?
You take the content from the base scripts and you put the content back into the same scripts. :confused1:

:cheers:

#24 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 13331 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 07 September 2011 - 03:05 PM

The two problems i see with you idea are:

1.) You start out from an unreliable source. So the result will be unreliable. (garbage in - garbage out)

Yes and no, the reliability will be proved by the test.
Sure, if you (or me :dubbio:) had actually written it, the .script it could be defined "reliable" (respectively by your or my ;) standards)

2.) Your proposed methode, works, if at all, only for app scripts and tweaks. One can't simply remove a base script from the build for a test. So it can never be tested, if a dependency of script X, is actually in one of the base scripts, where it doesn't belong.
So we're back at point 1.) gi-go.

I am talking of a "minimal" build.
This "mini-base" needs to be tested and verified once created.

What i just don't understand is, where you see the benefit of having the content of the scripts in a human readable database?
You take the content from the base scripts and you put the content back into the same scripts. :confused1:

The "human readable" in this case doesn't mean really "human readable", I am dreaming of something that can be used to show dependencies visually and what not, re-read the old post, please:
http://reboot.pro/2690/page__st__22
Please take also some time re-reading the at the time given example of the kind of problems that could easily be spotted and solved:
http://reboot.pro/2675/

Anyway, you are wasting your time, I have no idea HOW this can be done, you think it should NOT be done, and noone else is interested to this.
Dead end. :frusty:



:cheers:
Wonko

#25 MedEvil

MedEvil

    Platinum Member

  • .script developer
  • 7771 posts

Posted 07 September 2011 - 04:06 PM

This "mini-base" needs to be tested and verified once created.

And here we have the catch. How do you want to verify? Against what?
The least you would need, to spot any error or problem, would be several independantly developed PE projects. Which we do not have.

I am dreaming of something that can be used to show dependencies visually and what not,

I get that. But the way you propose to create it, will give you a script dependency database, which noone will use to create anything new, since the scripts already exist.

What i wanted to create, is a dependency database based on files.
You pick a file, you want to include and you can look up all file and registry dependencies of that file and the dependencies of the dependencies.

If i, for instance, state in my project, that i want to include iexplore.exe, then i should end up having the whole 'Internet Explorer' fully working, in my build. Guranteed!!!

My main problem is still the same as it was.
When i watch a program accessing the registry in ProcessMon, i see that it tries to accesses a lot of keys, that arn't there, yet this is no error, but perfectly fine.
So, when i read the registry keys, that a file wants to access from the file, how can i tell, the ones really needed, from the ones not needed at all?

:cheers:




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users