Entries:
Comments:
Posts:

Loading User Information from Channel 9

Something went wrong getting user information from Channel 9

Latest Achievement:

Loading User Information from MSDN

Something went wrong getting user information from MSDN

Visual Studio Achievements

Latest Achievement:

Loading Visual Studio Achievements

Something went wrong getting the Visual Studio Achievements

Carolyn Napier and Tyler Robinson (MSI team) - Installing apps in Windows Vista

Download

Right click “Save as…”

Windows Vista evangelist Ernie Booth came into my office a few weeks back and said "hey, let's go interview the MSI 4.0 team." Who's that? That's the team that makes the application install technology that'll ship on Windows Vista. Your app will probably use their technology to install, so you'll want to hear this and see the demos they do for us.

Tags:

Follow the Discussion

  • This was nice and interesting, but I still miss one thing from MSI, that seems extremly critical: auto updating. Here is the problem: Almost any software package that interacts with the internet will need to deploy security patches automatically to users. As far as I can tell, MSI really doesn't help you with that at all, while it really should. Essentially, as a software developer, you have two options right now: 1. Within your normal app check regularily whether an update is available and if yes, apply the patch, or 2. write a little background service/program that checks whether a new version is available even while your program is not running. 1 is not ideal, since your software might not run all the time and you might end deploying the securtiy patch too late. Soo, 2 is the way to go. A lot of software packages to it that way today. And the end result is that my system is packed with a lot of programs/services, that start at boot time, that do nothing but check whether an update is available. As far as I can tell this is minimally the case for Java, QuickTime, Realplayer, Logitech Camerasoftware and a couple more which I forgot. This is dreadful! They take memory, they take processor cycles, they might have bugs. But, I can't even blame the developers for doing it that way, since it is really the ony possibility today. The right solution to this should probably look like this:

    Within any MSI file provide the ability to specify an URL where patches will be posted by the ISV. Then, let the Microsoft Update engine check these locations for all installed MSI files regularily, like it checks for updates of Office etc. Just integrate third party updates into the Automatic Update feature of Windows, but ONLY requiring extra info in the original MSI file to take advantage of this feature. You would really do the whole Windows platform a great service, since a ton of these super annoying background processes could go away.
  • ZippyVZippyV Fired Up
    I think possibility number 1 is the way to go now: only check for updates when application is active.

    I like your idea for integrating all application updates with Microsoft Update. We really need one central place for updates.
  • If this Restart Manager functionality is taken up, it could potentially mean that Windows could gain the feature that Gnome and other Linux window managers currently have that lets you save the whole desktop state across reboots. Basically, upon shutdown you use the Restart Manager interfaces to persist the state of all running processes, which is restored when you log in again after the computer comes back up. This would be cool, and it seems a shame to relegate the functionality to being part of the Windows Installer component rather than a wider Windows metaphor.

    BSP
  • ZippyV wrote:
    I think possibility number 1 is the way to go now: only check for updates when application is active.


    The problem is that there is a class of apps where this is too risky. I fully understand that Realplayer, Java, Quicktime and thelike can't to it that way. If someone just very rarely watches videos in his browser that instantiate the player there is just a way to high likelyhood that he/she will hit some content that has malware against which the patch hasn't been applied at this first viewing.

    Also, while there is another class of apps where option 1 would be nice, it seems that a whole lot of ISVs still opt for 2. I as the user pay the price by having countless services wasting my resources. The real solution here is to have a platform service that takes care of this.
  • There is another twist to this. But first, a disclaimer: If argue under the assumption that MS won't have something like this AutoUpdate for third party MSI packages in Vista. If I am wrong, please disregard.

    Wasn't there talk that security would ALWAYS trump nice features in Vista? So, I assume MS at some point had to figure out whether to do AutoUpdate (I operate under the further assumption that they came up with that idea in the first place internally) or integration with restart manager. Hell, how could you decide for restart manager and against AutoUpdate in that case?!? Sure, if you mean by "We improve security only in our code", yes. But if you take the postion that security is an industry problem and once you realise that NOT having auto update for MSI in the platform will lead to significant worse security than having it in, this seems to be a no brainer to me. Am I wrong?

    I just feel that having a seperate auto update feature for every app on the system is error prone and will decrease security. Just the sheer number of different configurations will completly confuse users, so that when in doubt they will just shut it off. Also, at some point I just HAD to disable some auto update services on an old machine since they took so much system resources that I was hardly able to use it for anything meaningful anymore.
  • ZippyVZippyV Fired Up
    I am subscribed on the WIX-user list and I noticed that you still need exe bootstrappers. If you want to install an .msp patch or an upgrade .msi you need the exe to do do something like "msiexec /p application11.msp REINSTALL=ALL REINSTALLMODE=vomus".

    Why can't we just click on the msp?
  • Martin Ennemosermawcc Make it so
    buggy123 wrote:
    If this Restart Manager functionality is taken up, it could potentially mean that Windows could gain the feature that Gnome and other Linux window managers currently have that lets you save the whole desktop state across reboots. Basically, upon shutdown you use the Restart Manager interfaces to persist the state of all running processes, which is restored when you log in again after the computer comes back up. This would be cool, and it seems a shame to relegate the functionality to being part of the Windows Installer component rather than a wider Windows metaphor.

    BSP


    But isn't that already available in Windows, called Hiberation?
  • PerfectPhasePerfectPhase "This is not war, this is pest control!" - Dalek to Cyberman
    ZippyV wrote:
    I am subscribed on the WIX-user list and I noticed that you still need exe bootstrappers. If you want to install an .msp patch or an upgrade .msi you need the exe to do do something like "msiexec /p application11.msp REINSTALL=ALL REINSTALLMODE=vomus".

    Why can't we just click on the msp?


    Stange, I've use applications that allow you to just click on the .msp file to install it.

    Stephen.
  • GRiNSERGRiNSER GRiNSER puts a smile on your face :)
    will installers look more fancy in vista? like some on mac OS X?
  • Auto-updating over the internet is a bad idea and if you are currently doing something like that you should migrate away from it.

    The #1 mistake that software developers are making these days is assuming people will be administrators on their machines and assuming that people can update software.

    If Microsoft succeeds with its LUA/UAP goal for Windows Vista then most people will not be running as an administrators on their machine which means that all of these auto updates that apps are doing these days will fail.






  • jphillips59 wrote:

    The #1 mistake that software developers are making these days is assuming people will be administrators on their machines and assuming that people can update software.

    If Microsoft succeeds with its LUA/UAP goal for Windows Vista then most people will not be running as an administrators on their machine which means that all of these auto updates that apps are doing these days will fail.



    don't think so. if you watch the video again you'll notice that if the msi has a certificate of the author embedded into it the non-administrator user can allow the app to go to the web and update itself. msi engine will automatically raise the privileges to admin level for the application during install. this is only true if the app has been installed by an administrator, though... at least that's what i got from the video.

    regards,
    martin.
  • This is awesome. Do updates for products such as Windows and Office come as MSI patches? If so, does this mean that my Add/Remove programs dialog box will let me show updates for only Windows and Office that i can uninstall? That would be awesome.

    Now, to make sure that everyone uses Windows Installer!
  • ZippyVZippyV Fired Up
    Windows is not installed using the Windows Installer technology so Microsoft cannot use msi patches to patch Windows.
    Office however does use the Windows Installer technology and you can see which patches are installed for Office (and Windows too) in the add/remove programs dialog. But not all patches are uninstallable!
  • jphillips59 wrote:
    Auto-updating over the internet is a bad idea and if you are currently doing something like that you should migrate away from it.


    Depends, but I think we've seen what happens to business and people running old versions. Would you like to give your personal information to company still running Windows 2000 or older? It can be assumed that company isn't very up to date in their router, firewall and other software either. Bad guys will have a field trip in such companies, without the IT staff ever knowing it.

    jphillips59 wrote:

    The #1 mistake that software developers are making these days is assuming people will be administrators on their machines and assuming that people can update software.

    If Microsoft succeeds with its LUA/UAP goal for Windows Vista then most people will not be running as an administrators on their machine which means that all of these auto updates that apps are doing these days will fail.


    The software should keep itself up to date. When the software is first installed, if future updates require admin right, the installation will most likely also require admin rights - thus it will be possible for the software to make itself have permanent rights it needs for the auto-update or use some system provided auto update service.

    User should only be inconvenieced when the update involves breaking changes and other things user might be interested in.

  • Is the MSI team monitoring this thread? What about some insight on the auto update thing and what the MS reasoning behind that is? The whole point of channel9 is two way communication, right? Smiley
  • I'm not actually on the Windows Installer team but I do a lot of work on the WiX toolset (mentioned above).  We recently (like this weekend) added a new tool, called ClickThrough, to WiX that enables you to build auto-updating setup packages that take advantage of auto-update using RSS.  I have a blog entry  http://blogs.msdn.com/robmen/archive/2005/11/08/490448.aspx that talks about it in more detail.

    Like many of you, I'd like to see a solution in the platform but until then we're building technologies in the WiX toolset to enable many of the scenarios people describe above.  Also note that the WiX toolset is Open Source so if you want to see how it is done or contribute to the cause, you're welcome to join the community.
  • davida242 wrote:
    Is the MSI team monitoring this thread? What about some insight on the auto update thing and what the MS reasoning behind that is? The whole point of channel9 is two way communication, right?


    As a matter of fact, we are. Smiley We are looking forward to reading what everyone thinks of our new features in Windows Vista. Also, if you are interested in hearing more about Windows Installer 4.0 you can:
    Now, to address some specific questions on the thread so far ...

    buggy123 wrote:
    Basically, upon shutdown you use the Restart Manager interfaces to persist the state of all running processes, which is restored when you log in again after the computer comes back up. This would be cool, and it seems a shame to relegate the functionality to being part of the Windows Installer component rather than a wider Windows metaphor.


    The Restart Manager is actually a standard set of Win32 API's that will be available for anyone to plug into. Some information about this was given in the Reliable Apps PDC 2005 (FUN308) talk. So, while the Windows Installer provides the easiest way to support the Restart Manager from your installation, it is not the only way.

    ZippyV wrote:
    Why can't we just click on the msp?


    The Windows Installer has always had the ability to create double-clickable patches, you just had to do some extra authoring as part of the patch creation process. As of Windows Installer 3.0 (Windows XP SP2), we added automatic support for double-clicking of MSP files without any extra authoring required.

    Lots of people wrote:
    What about auto-update?


    The Windows Installer provides lots of technologies that enable auto-updating of applications on Windows Vista. For example, if you combine our UAP Patching functionality along with our Restart Manager integration, you get a really great experience where applications can easily update themselves without requiring the end-user to consent to elevation and with the application automatically shutting down and restarting to mitigate the reboot. Additionally, our existing feature that allows you to apply patches at the time of install makes it super-easy for a bootstrapper to check the internet for updates and apply them automatically at install-time.

    Granted, this isn't the centralized universal update mechanism in the operating system that many would like to see, but I think the Windows Installer has made great strides towards improving the application update story in Windows Vista.

    Thanks so much for your comments, and please remember that we have an upcoming MSDN Chat on Tuesday, November 15 that focuses specifically on our Windows Vista feature set. Please attend.

    - Tyler Robinson
    - Program Manager
    - Windows Installer Team
  • ZippyVZippyV Fired Up
    What about the integration idea with MicrosoftUpdate?
    1 central place to update all your (msi) applications. What about companies that deploy applications using Active Directory? Can they use WSUS to update all those 3th applications?

    Sorry Robmen, but I don't think Clickthrough is the way to go. Sad
  • buggy123 wrote:
    Basically, upon shutdown you use the Restart Manager interfaces to persist the state of all running processes, which is restored when you log in again after the computer comes back up.

    Note that Restart Manger itself doesn't save the application's state. It only tells the app to save its state, then closes the app and later re-starts it. The app needs to be coded such that it responds to the message from Restart Manager and saves its state. I too find this cool, and I hope that application developers will start to prepare their apps to support this.
  • davida242 wrote:
    Wasn't there talk that security would ALWAYS trump nice features in Vista? So, I assume MS at some point had to figure out whether to do AutoUpdate (I operate under the further assumption that they came up with that idea in the first place internally) or integration with restart manager. Hell, how could you decide for restart manager and against AutoUpdate in that case?!?

    There are two problems in the update story: 1. Being notified about available updates (or app automatically checking for updates), and 2. actually applying them. Often updates don't get installed because they would require a reboot or at least a restart of the app, which the user doesn't want to do right now*, or there's no user sitting in front of the machine to save their open documents when you deploy updates at night. Restart Manager can help with problem number 2.
    But I agree that a central location for all updates would be great.

    * Typical situation: When I double click a PDF file Adobe Reader tells me that an update is available. But at that very moment I want to read the document, not install an update, so I decline the update.
  • When is the MSI team going to fix the DLL Hell Part 2 that they've created?

    I mean take a look at uninstalling VS.NET 2005 and SQL Server 2005 and you'll know what I mean. (and there is actually a tool to uninstall the betas etc because it's so damn hard to do it right!!!!)

    Please please please for V4 of the Windows Installer engine provide us with the ability to sign Merge Modules and patch them separately from the application.

    By doing this you achieve the following:

    1. A Microsoft signed merge module could then write to the system directories thus updating/installing system components. (Add this functionliaty for a special exception to the rule please!)
    2. Patching the modules gets rid of the reason why the MSDE merge modules were pulled. By allowing patching of merge modules (registered on the machine separately) all merge modules and system components can be updated independant of the application thus allowing MS to update the system components that were installed via merge module without relying on 3rd parties to patch their applications.

    End result, by doing these two small things and implimenting an exception to the "no install to system dir" rule (and also allowing by pass of System File Protection for signed merge modules from MS) we get rid of the need for all bootstrapping and can again provide our end users with a seamless install experience and only install those things that are actually needed to be installed by our application based on the choices of our end users instead of having to install every system component even if it isn't needed for the choices of the user (i.e. SQL Express Edition etc.)

    Please please please put this in and end the bootstrap crap. A boot strap should only be needed (and included in the dev kit) to download and install (or grab off of the CD) the Windows Installer V4.0 setup and then run the installation. There is NEVER an excuse for anything else to be installed before the application installer runs. It should all be done transparently for the user. There is no reason why the end user should ever know that SQL Server Express is also being installed on the computer. And the end user shouldn't ever have to know to uninstall SQL Server Express separately from the application to get rid of your application on uninstall (i.e. VS.net 2005, SQL Server 2005 mess in Add/Remove Programs)

    I can't say enough about how important this is to fix. It is the most important thing of ANY bug (yes it's a bug) that MS has in any of its products that need to be fixed. You're creating an installation experience that results in users being confused and the uninstall experience is even worse (you shouldn't need a knowledge base article to be able to correctly uninstall an application, and if you dont' follow it you can end up with a non-functioning installation of the OS, both of which can happen uninstalling VS.net 2005 and SQL Server 2005 by hand now)

    Please fix this.
  • KenQKenQ Who's richer, the guy with the dough or friends?
    Stefan Krueger wrote:


    * Typical situation: When I double click a PDF file Adobe Reader tells me that an update is available. But at that very moment I want to read the document, not install an update, so I decline the update.


    I so totally agree with that. I just hate using Adobe reader for that reason. They seem to ship updates every week (more or less) Tongue Out

    Seriously, a central way of updating ALL your applications (regardless if there were written by Microsoft or not) would be a dream come true. Especially for us IT-administrators. It's not too fun to browse the web all over just to see if there's an update available or not. I'm not saying that it's Microsofts responsiblity to notify the users of thirdparty updates, but it sure would be cool if someone took the first step and made it all easier somehow. So why not the one with the core?Big Smile
  • jphillips59 wrote:
    Auto-updating over the internet is a bad idea and if you are currently doing something like that you should migrate away from it.

    The #1 mistake that software developers are making these days is assuming people will be administrators on their machines and assuming that people can update software.

    If Microsoft succeeds with its LUA/UAP goal for Windows Vista then most people will not be running as an administrators on their machine which means that all of these auto updates that apps are doing these days will fail.


    Furthermore, most administrators want to keep consistency and upgrade only after they have thoroughly tested updates.  Relying on end-users to update their own desktops is not an option--you end up with a hodge-podge of different patch levels for different applications from machine to machine.  Worse yet, as you add integrating apps into the mix--a couple plug-ins to Outlook, say--things can get really nasty.  Update plug-in A, plug-in B breaks; update plug-in B, plug-in A breaks; or better yet, update either, and take out Outlook altogether.  Giving the end user the ability to update at their whim--even if it's a security update--is something that must have a switch that administrators can turn off (perhaps through Group Policy).  There are usually work-arounds for security issues, and you can't let a security update totally stop the company.

    Edit--Nevermind, I see that they mention this in the video.  The administrators can turn this function off. (Yay!)
  • ShadowChaserShadowChaser It's not easy programming with paws.
    I only beg and plead, on my hands and knees, for a single new feature in MSI:

    Do whatever it takes to add the functionality into MSI to let me install MSDE/SQL Express as part of my own MSI installer. And also let it uninstall my custom instance when my app is removed.

    If the functionality already exists in MSI, go to the SQL team's building and give them evil stares until they fix it.

    I can't stress enough what a nightmare it is trying to bootstrap these things onto the front end. Bootstrappers don't deploy over IntelliMirror/SMS! [C] Expressionless Perplexed
  • DCMonkeyDCMonkey What?!?
    KenQ wrote:

    Seriously, a central way of updating ALL your applications (regardless if there were written by Microsoft or not) would be a dream come true.


    Be careful what you ask for there or you'll end up with cack like the "InstallShield Update Manager". When I first saw this braindamage pop up in the taskbar tray I was like, WTF? An update manager for the freakin install program? Well, it turns out that it is also a shared update manager for other programs. How I was expected to be aware of that I do not know. I just wanted the abomination to sanity off my system. I'm not even sure what junkware that came with my new Dell relied on it, since I managed to uninstall most of that as well.

    I'm sorry but end users don't give a rats hindquarters about the InstallShield brand. Keep that to the MSDN magazine ads.

    And while we're on the subject of both Adobe Acrobat Reader and inappropriate brand whoring, what's up with the "Netopsystems FEAD optimizer" technobabble you get when installing the Acrobat Reader trhese days? Adobe, did you ever consider just saying "decompressing" or "unpacking", or dare I say "installing" while showing a progress bar? And while you're at it, add a cancel button to that dialog. Its absence was made all the more obvious as I once  watched the "decomposition" process crawl for several minutes on an older machine, left only to bask in the dialog box's utter ridiculousness.

    On a similar but more subtle note, Why do the dialogs on some uninstall routines display messages like "configuring UnwantedProgram". Shouldn't it just say "uninstalling UnwantedProgram"?

    Bah.

    </rant>

    Sorry for that. I just had to unload. Spending a couple hours uninstalling all the crud Dell puts on a new PC will do that to you.

  • I have a question about how it will save state and reboot the system.  On a fully locked down machine, lets say you have it install something it appears to be done it reboots and then the use logs in to complete the install (not the admin), does it encounter the same problem as it currently does?  Or will the Windows Installer Service be running with special privileges that will enable to take full control of the system to handle a download without user interaction? (this is how it should work, perhaps with signed msi's only or something for security?)

    Anyways just curious...

  • Hello everyone,

    We have been keeping a close eye on the thread here and I wanted to reply to some of the messages...

    John Galt wrote:
    Please please please put this in and end the bootstrap crap.


    The Windows Installer team completely understands the pain associated with bootstrappers, and we will be working hard in the future to address the situation. Unfortunately, we were not able to do this work in Windows Installer 4.0, but rest assured that we will be looking at this very closely for our next release.

    KenQ wrote:
    Seriously, a central way of updating ALL your applications (regardless if there were written by Microsoft or not) would be a dream come true.


    I agree completely with the other sentiments on this thread that the operating system really needs a central application update mechanism. I believe that the Windows Installer 4.0 provides the necessary infrastructure so that it will be possible for Microsoft (or a 3rd party) to build such a solution in the future.

    And finally, thanks to those of you who attended our Windows Installer 4.0 chat on Tuesday. If you were not able to attend, a transcript will available here within the next few days.

    - Tyler Robinson
    - Program Manager, Windows Installer
  • ShadowChaser wrote:
    I only beg and plead, on my hands and knees, for a single new feature in MSI:

    Do whatever it takes to add the functionality into MSI to let me install MSDE/SQL Express as part of my own MSI installer. And also let it uninstall my custom instance when my app is removed.

    If the functionality already exists in MSI, go to the SQL team's building and give them evil stares until they fix it.

    I can't stress enough what a nightmare it is trying to bootstrap these things onto the front end. Bootstrappers don't deploy over IntelliMirror/SMS!



    ShadowChaser:  See my post. This is what MS has to do to fix this bootstrap uninstall nightmare that they have created. Instead they seem fixated on boostrappers as a way to solve the problem instead of fixing the originating problem that caused bootstrappers to be necessary in the first place.

    Fix the real problem, don't bandaid it please!!!!!!!!!
  • Windows Installer Team wrote:
    Hello everyone,

    We have been keeping a close eye on the thread here and I wanted to reply to some of the messages...

    John Galt wrote:Please please please put this in and end the bootstrap crap.


    The Windows Installer team completely understands the pain associated with bootstrappers, and we will be working hard in the future to address the situation. Unfortunately, we were not able to do this work in Windows Installer 4.0, but rest assured that we will be looking at this very closely for our next release.

    - Tyler Robinson
    - Program Manager, Windows Installer


    Don't bother releasing a new version until you've fixed Bootstrappers.  Update features are a pointless waste of time until you give us a seamless single install point. You're greatest problem is exemplified by trying to uninstall VS.net 2005 and SQL Server 2005.  Do whatever it takes to fix this NOW as opposed to later and worry about the rest later.  There are a ton of 3rd party systems (Wise for example) that give Windows Installer most of this functionality.  However, there is absolutely NO WAY to get around the bootstrap disaster. Yes it is a disaster and I'm not exagerating. Any application that needs a KB Article and a uninstall tool released by the dev guys that wrote it after the fact is a disaster waiting to happen. Windows Installer Team should be absolutely asshamed that they have created this mess. And be doing whatever it takes to undo this and posting a huge appology to both 3rd party people forced to use Windows Installer and to the dev teams in MS that have to release crapware that can damage an OS installation of not uninstalled with careful instructions that are many pages long.

    Get your priorities straight People.
  • ShadowChaserShadowChaser It's not easy programming with paws.
    John Galt wrote:

    ShadowChaser:  See my post. This is what MS has to do to fix this bootstrap uninstall nightmare that they have created. Instead they seem fixated on boostrappers as a way to solve the problem instead of fixing the originating problem that caused bootstrappers to be necessary in the first place.

    Fix the real problem, don't bandaid it please!!!!!!!!!


    True, but MSI is a fairly complicated platform, and certain changes might cause serious problems to existing apps.

    I do agree 100% about the bandaid comment though, but bootstrappers have been around for ages. Creating a bootstrapper *is* a good stop-gap solution, but I do think that eventually this problem needs to be solved.

    I don't think it's the windows installer team's fault - it's more that they've been left out of the loop on decisions made by other teams - system file protection would be a good example. The other product teams (MSDE, Windows Security/Patching, etc) seem to run into a small snag - some function or minor API windows installer is missing.

    They then create large hacks and workarounds, causing serious problems for ISVs. If they had just worked together to add the functionality to windows installer in the first place, none of this would be an issue.

    Updates is a big concern as well though -  as big as the bootstrapper problem. Most "app updaters" run with the assumption that the user is logged in as an administrator - which is a very bad thing for security. As a developer *and* and IT guy, I find it extremely frustrating how many applications completely ignore LUA best practices. Integrating low-trust user app updates into MSI seems like a great idea to me, and does fit nicely into the Vista feature set. I wouldn't get too upset about it:)
  • Sure, updates are a good thing.  But on hitting a brick wall that completely destroys usablility for an application, bootstrapping is it.

    And I can't believe for a second that the Windows Installer team is out of the loop at any step of these teams running into this stuff.  If they are, then there is a collosal problem in MS that needs to be fixed and people's heads need to roll over it.  I know for a fact that both the VS.net and SQL Server 2005 teams were bitching about this very thing regularily, and I don't think ANYONE missed Slammer which was a large part the responsibility of the Windows Installer team's mistakes with design in Windows Installer. They would to have had their heads so far up their ... that they would have been tickling their tonsils.

    This has been coming for almost 6 years now, they had lots of warning and have chosen to not do anything about it. That's unacceptable and inexcusable. 6 YEARS!!!!
  •  I really like these series, but I have to say incompetence from the interviewers is really annoying.
     We are informed users. In this clip for example, the interviewer is good, he's quiet and asks questions that are pertinent.
     The cameraman however, annoys the hell out of me. I don't watch these videos to hear someone complain about how someone's computer had to reboot last night because of updates, and more than once he interrupts interviewees from saying what they have to say. This isn't Fox News.

     Kudos on the interviewer. Cameraman, shut it and listen: you might learn something new.
  • Dude, the guy running the camera is Scobelizer...the same chap that created this series!

    Pv

Remove this comment

Remove this thread

close

Comments Closed

Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation, please create a new thread in our Forums,
or Contact Us and let us know.