I am working on many apps that uses RegFree COM Activation, everything works well except that one of the application is ran using an older technology that uses a JIT-type compiler.
To get RegFree COM working, i have to provide a manifest to the launching executable (correct me if i'm wrong) with my dependencies listed. All my other applications are built in-house and i have full control over my manifest (authoring and if i embed it, if i leave it Side-By-Side, etc). But this JIT-compiler (ala Java JRE) isn't mine and it already contains (embedded) a manifest.
I've extracted the manifest (using MT with -inputresource and -outfile), modified it and re-embedded it. It works like expected. However, having no ownership over this executable, i am worried about the legality of such a manipulation (modifying a third party's executable and redistributing it!) and would like to avoid having to do such a thing.
Also, i am worried that at some point this executable may be signed by the third-party and thus modifying the embedded manifest is going to break the signature.
Is there a way to have the sxs-loader look for another manifest first? It seems that if it finds one embedded, it takes it by default (which under most cases is fine).
Can i provide a configuration file or anything that would skip the embedded manifest and go for my side-by-side provided one (myExe.exe.manifest, instead of RT_MANIFEST resource inside myExe.exe) ?
You can only do that system wide as far as I know. Add that to the registry:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\SideBySide]
"PreferExternalManifest"=dword:00000001
Make sure to trip activation context cache by updating last modified date on your executable, otherwise your manifest changes won't be picked up (renaming and renaming it back seems to work).
On Win XP external manifest is preferred over internal, but since Windows server 2003 Service Pack 1 they changed it to opposite.
Related
We have a SPA web application that we're trying to convert into a WinJS project as a native Windows Store app. For most part, the Javascript is working except for DOM manipulations deemed unsafe.
One thing that does not appear apparent is, how can the start page of the app (e.g. index.html) be supplied with query string and hash parameters? Our site main page is designed to behave differently based on parameters.
e.g. index.html?contextId=xxxxx#enviroment=xxxxx
I tried adjusting the value in package.appxmanifest to no avail. It will throw errors on query strings, and hash parameters will silently not persist.
UPDATE: Project background
A brief about what our app does, and then why the above naive desire won't work and the answer below how we went about this issue.
Our web app is a highly-dynamic data-driven application that completely relies on data to figure out what to render. Therefore the ?contextId=xxxxx parameter is so crucial as it tells our system to load the data which further informs what kinds of visual components to load and it goes on recursively to form wildly different UIs.
We were looking to therefore find some means to supply these parameters like traditional command-line parameters to the same executable to produce different UIs. And thus different "apps" by mere changes in those parameters. Like a "config transform" mechanism for web.config in ASP.NET web projects, that would be most welcome.
However further testing showed it is not possible; a single Windows store app project has a GUID that is supplied into the packaged app bundle. Building the same project multiple times with different "build config" would just mean overwriting a previous installation since they are the same app with increasing version numbers. The answer details how we went about this.
Windows Store apps don't work with URI parameters when launched from their primary tile. In that case, you should make sure that the app defaults to suitable values, e.g., if you were thinking to supply defaults in the manifest, then default to those in the app's activation handler for the ActivationKind.launch case when eventObject.detail.arguments is empty.
There are two other ways to launch an app that can supply other arguments.
First is to launch via a secondary tile. When you create the tile from the app (which is subject to user consent), you supply the launch arguments. In your activation handler, for ActivationKind.launch, those args will be in the eventObject.detail.arguments property.
Second is to launch the app through a URI association. You use a custom schema for this, which is declared in the manifest. The app will then see ActivationKind.protocol and eventObject.detail.uri will contain the full URI including any parameters. A URI launch can be done from another app, by entering the URI into a browser address bar, or through a shortcut that a user could configure on the Start screen.
The first step is to convert our Windows (8.1) Store project into a Universal app structure, which would then spin off a separate Windows Phone WinJS project (this is nice when we wish to target Windows Phone later) and a shared project.
Practically everything from the Windows Store project is moved to the shared project (including default.html or index.html). What remains in the Windows Store project is a customised config.js carrying the parameters
window.customWin8 = {
contextId: xxxxxxxxxx,
customParam: 'xxxxxxxxxx'
};
The downstream modules that sense for query string/hash parameters would then fall back to this alternative object if it exists to pick up the data it needs.
Now, for every differing app we wish to deploy, that would for now seem to require a separate Windows Store project so it gets its own GUID and won't conflict with other apps. All these projects would reference the very same shared project thanks to the Universal structure Visual Studio affords. The only down side is it seems Visual Studio 2013 does not have a direct UI method to make this referencing to the share project and has to be hand code into the jsproj file.
<Import Project="..\Common.Shared\Common.Shared.projitems" Label="Shared" />
With this adjustment they can all build and package with their isolated "build config".
I have a 3rd party executable which I am trying to include in an InstallShield MSI package and I want it to have permissions set in all flavors of Windows, particularly 7 & Vista to be run as Administrator.
I'm not that clued up on the creation or the proper configuration syntax of Manifest files, but I have tried to make one manually as [appname].exe.manifest, and tried the <requestedExecutionLevel level=”asInvoker” uiAccess=”false” /> in the XML, and it didn't run as Administrator, and I want to confirm that is that because the program had not been compiled that way to see that the manifest file was in the same directory, or is it just going to be a case that the manifest file has not got the right syntax.
If there is any other simple ideas, I would love to hear it!
Cheers.
Manifests can either be embedded into an executable (this is preferred) or external, placed next to the file named as you describe. If there is an embedded manifest, an external one is ignored. For launching EXEs, this is all performed by Windows, and is not affected by code in the exe file. For loading DLLs, while this can be somewhat influenced by code you write, it does not change UAC behavior as it is not a process boundary.
As for whether a program not launching as administrator when you place a manifest requesting asInvoker next to it means you created a valid manifest, that depends on what happens when the manifest is not there. Since you mention InstallShield, you can copy a template manifest file such as its <InstallShield>\Support\setupexe.invoker.manifest to ensure your syntax is correct.
Upon re-reading your question, I realize you wanted it to launch as administrator. For that you need to request administrative rights, so you should have requireAdministrator instead of asInvoker, or base it off setupexe.admin.manifest instead.
You'll have to bear with my slightly on this, but please ask if I have left out any pertinent information. I have just taken over a project to create a dashboard for my team. This dashboard has been made using a niche third-party tool that nobody here will have used before. The third party tool auto-generates some code to display "markers" on a webpage. "Markers" being some proprietary code to query a database/apply custom styling etc.
I am trying to display a webpage within the page that has been generated, and I’d like to point this to a local webpage (ie on my C drive). If I pass it an absolute path, then this results in a warning in IE9 as I am mixing data sources - a https website pointing to a http web page. It will display after ignoring the warning, but my userbase is not comfortable enough with computers to ask them to do this.
I believe if I pass it a relative path then it should work, but I can’t find out what directory to base this path off and it doesn’t appear to be anywhere obvious. So, in my current page I have an image with the web address of : https://website:8443/websitereport/images/buttons/locked.gif. What I need to know is where the “websitereport/images” folder is stored so that I can put my webpage in there to give the webpage a relative path. The HTML for this image is :
<img id="dvp_locationbar_lock" class="dvp_imagebutton" style="" dvp_title="ui.tip.lock-page" dvp_image="locationBarPageUnlockedImage" src="/websitereport/images/buttons/unlocked.gif" title="Lock this page">
What are my options for discovering where this folder is stored locally? I am running Apache Tomcat 7.0. It is not displaying if I use the path based off
C:\Program Files (x86)\Apache Software Foundation\Tomcat 7.0\work\Catalina\websitereport
of
\websitereport\page.html
And I cannot find it anywhere obvious in the Apache folder. I have tried :
Searching - no results.
Using PHP to print the current working directory - cannot find out
where to edit the webpage.
Looking at images/information on the existing webpage. They all point
to folders I cannot find.
Inspecting with firebug.
In short, you can't rely on the files being on disk at all - they might be just contained in a *.war file, containing the whole application. Or they might be generated on-the-fly, despite the name sounding like an actual file.
Also, you should not arbitrarily write within a directory even if you find it (my closest guess would be tomcat's webapps/websitereport/ directory if it exists) because nobody will know that something changed during the time since last deployment. So, on the next update of the application, you'll end up overwriting all of your changes again. You typically change the underlying application and redeploy.
You might also find a few references in tomcat's conf/localhost/ directory or even in conf/server.xml, but it all depends on how your server was administered
I have finished an extension for my company and I want to put it on the company wiki so that in order to get it on everyone's machine all I have to do is go around and click the link.
First, I HAVE READ all the documentation from http://developer.chrome.com/extensions/hosting.html about hosting and autoupdating and all that. Part of it confuses me and I can't find any more information about this:
Google Chrome considers a file to be installable if either of the following is true:
The file has the content type application/x-chrome-extension
The file suffix is .crx and both of the following are true:
The file is not served with the HTTP header X-Content-Type-Options: nosniff
The file is served with one of the following content types:
empty string
"text/plain"
"application/octet-stream"
"unknown/unknown"
"application/unknown"
"*/*"
This looks like it wants a MIME style setup? but I have never done anything with this. I have the ability to change what I want to the Locally hosted Wiki, all I need is to understand what need to change to make the link installable. I will keep looking for examples.
Note: The reason it is not going on the app store is that there is really no reason to. It is branded for our company, and communication with our specific servers is hard-coded into it.
In version 21 (or so), Chrome disabled the ability to do a simple link-click install of off-store extensions. There is a discussion of the change in this bug report:
You are no longer supposed to be able to install extensions off-store in Chrome... In order to install off-store extensions, the user must download them to a directory and drag them onto chrome://extensions/.
There is, therefore, no longer any way to install an extension simply by clicking a link, except by hosting it in the Web Store. You will need to download the file and then drop it into chrome://extensions.
The documentation you reference looks out of date (that's Google's fault, not yours). It definitely fails to mention the new drag-and-drop requirement. It also talks about the file's "content type" and the X-Content-Type-Options HTTP header required to make the CRX installable; however, when you install an extension by dropping it into chrome://extensions, I doubt very much that Chrome remembers what HTTP headers were set when you first downloaded the file.
EDIT: You can also use the --enable-easy-off-store-extension-install command line flag to restore the old instalation behavior.
You can do an "inline install" of an app hosted on the web store. The new changes are forcing people to move our extensions to the web store, but the inline installation should allow your users to not need to leave your page to install.
We are trying to distribute a basic HTML file with some links to a PDF document in a USB drive for advertising purposes. The idea is that an autorun opens up this HTML in the default browser. However, this might not be a good idea since it would look very amateur-ish and we will have to rely on the default browser's technology (which unfortunately has a good chance on being IE6/7!)
We've explored a few alternatives, but we can't find one that really fits what we are trying to achieve:
Mozilla Prism
Altough it seems like it's designed with offline web apps in mind, the executable creates files in the user's AppData directory and it's hard to configure the default paths. Also, Firefox doesn't have a default PDF viewer, so we will have to depend on the user's default PDF viewer (which might be Adobe Reader)
Mozilla Chromeless
Since Prism is inactive, the idea is still developing with Chromeless, which allows the developer to create the browser interface with basic HTML/JS/CSS. The main issue here is that somehow the build isn't loading HTML, all that's showing is a gray iframe. I'm not sure if it's just me, because there's nothing on the issues page.
Portable App
We could throw in the portable version of Firefox or Chrome and customize the XUL for Firefox or open Chrome in app mode.
Firefox's advantage is that it kind of supports relative paths (resource://), but it doesn't have a built-in PDF viewer. Chrome has a very good and lightweight PDF viewer and the built-in app mode is a very useful feature for us, but I can't find how to open a local path without the usual absolute path (file:///C:/) since we don't know what's the drive's letter.
Has anyone figure out how to handle this kind of issues? Thanks.
This has been asked three years ago, but it's unanswered, listed high in Google, and I stumbled over the exact same problem and can imagine that many others that seek to ship portable web apps that can be run locally and with a minimum of dependencies will encounter this issue, too.
The solution I am now going with is the node-webkit.
You can treat it like a portable version of chrome, however it excepts a relative path to your app's entry point, is about 40 MB smaller, and much more customizable than the --app mode of chrome (which isn't customizable at all if I remember correctly).
Github & Download:
https://github.com/rogerwang/node-webkit#downloads
An extensive guide:
http://thejackalofjavascript.com/getting-started-with-node-webkit-apps/
My usage suggestion for Windows:
First create an app package as explained in the guide linked above
For the node-wekit to load with your app, you need to start it like this:
nw.exe app.package
Where nw.exe is in the root of the zipped folder you downloaded and app.package is a zip file (can have any name) that contains your app data and package.json.
To do this silently, you can use a BAT file containing the (amended) call above and a VBS file containing something like this:
CreateObject("Wscript.Shell").Run "cmd /c launchNW.bat", 0, true
launchNW.bat being the name of your BAT file. Now run the VBS file; a window containing your web app should pop up without the command window appearing with it.
Finish reading the linked guide to learn more about customization options to do things like hiding the browser UI etc.