I have an update function in my app - it downloads and verifies the installer (a setup.exe, created with NSIS). To actually kick off the update, I have simply been doing:
QString path = .. absolute path to the downloaded file ...
QProcess::startDetached(path, QStringList());
This works fine on XP - but on Vista and Win7, nothing happens once the download completes. If I browse to the downloaded update and run it manually, it works fine. I assume what's happening is that UAC is blocking the installer at CreateProcess time, but this is where my knowledge runs out.
Additional complication - when I'm running a debug build from the command line, the steps above work - I get the UAC prompt and can run the installer. It's the release builds, started form the start menu/shortcut, which have the issue - I assume there's a difference in the auth token when running from a command shell.
You can also use
QDesktopServices::openUrl(QUrl::fromLocalFile(path));
Might be surprising and counterintuitive, but it works and is more cross-platform
If you are not admin and you call CreateProcess() on a .exe with a "Vista" manifest (or no manifest, but a .exe that windows detects as an installer (This includes NSIS)) the call fails, you need to use ShellExecute[Ex](). ShellExecute will trigger UAC prompt if required...
This seems to be a Qt bug, see QTBUG-9761 , the correct workaround is to use ShellExecute with lpOperation set to runas.
Another alternative is to prepend your execution with cmd.exe /C. This effectively routes your execution through the shell, so you do get the UAC prompt. The downside is that if your process fails you probably won't get as much information had you gone through ShellExecute[Ex], but on the plus side you will get all the facilities of QProcess that you miss if you use QDesktopServices::openUrl, where you have no idea if things worked or not.
Related
In my Android Things app, I need to use su from runtime. However, Android Things system is built as userdebug build, so I can only access it from adb. I tried to both replace su binaries with no luck. I tried to disable ro.secure by unpacking and repacking boot.img, however flashed system still returns getprop ro.secure 0. How can I achieve root in my Android Things device?
I had these scripts working on a quite early preview version, maybe 0.1 or 0.2. https://github.com/fmatosqg/androidthings_ndk/tree/master/app/src/main/script
Although I had to run it manually, there should be a place where I can add this script so it runs every boot, just like linux's /etc/rc.d
I don't remember how I got the script to work, but the idea is that one script simply exists to launch the other running as superuser, similar to what you would expect with sudo <insert command here>
I have a simple application using
QT += core gui network webkitwidgets
I've used windeployqt.exe to generate the 32 bits release on my win-10 64 bit computer. When I put the folder on a win-7 64 Bit desktop and double-click the app.exe, it never starts.
I can see it in the task manager, but I can't kill it, and if I try I cannot close the explorer folder in which I double clicked anymore.
I've checked the usual platform, ICU, qwindows.dll, and so on.
http://doc.qt.io/qt-5/windows-deployment.html
EDIT Precisions:
I've compiled with default 32 Bit kit: "build-Test-Desktop_Qt_5_5_1_MinGW_32bit-Release" with "mingw492_32"
I have a package "release" generated by windeployqt.exe using the --webkit switch. I start a command prompt:
> set path=
> set mingw=
Then I make sure that no Qt/Mingw things exists anymore in my environment variables.
I also rename "c:\Qt" into "c:\ __Qt".
I move my release folder on my desktop.
I start release\test.exe ( from the clean path shell )
Everything runs fine! So The release/test.exe has everything it needs without the path/mingw variable.
But as soon as I put the folder on another windows machine ( 7 instead of 10 ) it never starts.
I tried dependency walker. It shows a lot of "API-MS-WIN*.dll" missing...
It even shows much more missing dlls on the "good" machine than on the bad one !!!
Every single "missing dll" on the "bad" target machine is actually in system32 on this machine.
Thanks for advice, every advice is welcome, I'm a bit desperate... :)
Edit
It seems to be related to the machine itself. I have successfully deployed this (very small) app to 2 non developer machine on win7 and win8 respectively. But the above "bad machine" still resits running it...
Edit
The problem seems not to be general but related to this one particular machine. Hence, feel free to close or move to the appropriate forum as it is not related to Qt/windeplyqt. If I figure out a solution, and question is closed, I'll simply add a last edit. Safe Boot and malwarebyte are my next actions.
After a long investigation.
Do not believe dependency walker, it used to be a top notch tool but it is now outdated.
If there is a missing dll, the system will prompt you with "cannot load dll xxx.dll" anyway.
Your best shot in case a soft runs on machine X but not on Machine Y is:
start in safe mode ( run: msconfig --> diagnostic startup )
turn off any antivirus or non microsoft/driver software,
"run as administrator".
If you can run with step 3. Then proceed by elimination:
run without admin rights,
Start anti spyware, etc...
Add appropriate exception to your antivirus if it is the root cause.
If the antivirus is not the root cause, run process monitor on both machines. Then compare, what Failed on one machine and not the other ? Read the windows event log and compare any error messages on both machines.
run sfc /scannow to check disk
run a complete anti spyware scan/ pc-repair tool ( malwarebytes, combofix, ... )
Make sure you really have the very same package on both machines, make sure you are not trying to run an exe on mac OS, make sure your computer is on.
Call the oracle, you are in the matrix...
In my case the problem was Avast and it was solved by adding appropriate exception.
I understood that anything to standard out (System.out) would appear in the Java Console window (when it's enabled). I spotted somewhere though that there might be situations where this isn't try, for example, from Swing apps. Is that the case?
Basically, what situations or setups wouldn't I expect to see standard output in the console? Is there a difference in behavior running on the JDK rather than explicitly on the JRE for example? javaw.exe?
ps, I understand how to display the Console in the Java settings but I'm curious as I've managed to create an application, run as an executable jar, that doesn't start the console despite some calls to System.out) on Windows 7.
The only way you wouldn't see System.out output in the console is if the method System.setOut has been invoked. This method is invoked to redirect output to the graphical Java Console, but I don't know of any other realistic circumstance in which it would be redirected away from the Java Console unless you do so voluntarily.
Depending on terminal settings it can happen that the output is not written until a newline character is sent as well. So if you do System.out.print("test") it might not appear immediately.
On Windows this is usually not the case, but on Unix terminals this is quite common.
Perhaps you use javaw to start virtual machine, this version will not show console messages. You can use java to start the virtual machine, which will show the console message.
javaw is intended for apps with windows, java is intended for console apps.
Same thing happened to me. I could not get System.out.println or Logger.debug either on console.
If you are on a huge project in Eclipse or whatever, you can read below.
Solution: I realized that I had not committed jars and some java files to SubVersioN on network. thats all. Project had not been compiled.
One situation I can think of is to invoke System.setOut(null) (orSystem.setOut(any OutputStream other than System.out or System.err)) then the console, if exists, would show nothing.
Does anyone know a good method to debug server side code?
I tried enable Node.js debug then use node-inspector but it does not show any of my code.
I end up using console.log but this is very inefficient.
Update: I found the following procedure works on my Linux machine:
When you run Meteor, it will spawn two processes
process1: /usr/lib/meteor/bin/node /usr/lib/meteor/app/meteor/meteor.js
process2: /usr/lib/meteor/bin/node /home/paul/codes/bbtest_code/bbtest02/.meteor/local/build/main.js --keepalive
You need to send kill -s USR1 on process2
Run node-inspector and you can see your server code
On my first try, I modify the last line on meteor startup script in /usr/lib/meteor/bin/meteor to
exec "$DEV_BUNDLE/bin/node" $NODE_DEBUG "$METEOR" "$#"
and run NODE_DEBUG=--debug meteor on command prompt. This only put --debug flag on process1 so I only see meteor files on node-inspector and could not find my code.
Can someone check this on Windows and Mac machine?
In Meteor 0.5.4 this has become a lot easier:
First run the following commands from the terminal:
npm install -g node-inspector
node-inspector &
export NODE_OPTIONS='--debug-brk'
meteor
And then open http://localhost:8080 in your browser to view the node-inspector console.
Update
Since Meteor 1.0 you can just type
meteor debug
which is essentially a shortcut for the above commands, and then launch node inspector in your browser as mentioned.
Update
In Meteor 1.0.2 a console or shell has been added. It may come in handy to output variables and run commands on the server:
meteor shell
Meteor apps are Node.js apps. When running a Meteor app with the meteor [run] command, you can configure the NODE_OPTIONS environment variable to start node in debug mode.
Examples of NODE_OPTIONS environment variable values:
--debug
--debug=47977 - specify a port
--debug-brk - break on the first statement
--debug-brk=5858 - specify a port and break on the first statement
If you export NODE_OPTIONS=--debug, all meteor command run from the same shell will inherit the environment variable. Alternatively, you can enable debugging just for one run, with NODE_OPTIONS="--debug=47977" meteor.
To debug, run node-inspector in a different shell, then go to http://localhost:8080/debug?port=<the port you specified in NODE_OPTIONS>, regardless of what node-inspector tells you to run.
To start node.js in debug mode, I did it this way:
open /usr/lib/meteor/app/meteor/run.js
before
nodeOptions.push(path.join(options.bundlePath, 'main.js'));
add
nodeOptions.push('--debug');
Here are additional practical steps for your to attach debugger eclipse:
use '--debug-brk' instead of '--debug' here, because it's easier for me to attach node.js using eclipse as debugger.
add 'debugger;' in the code where you want to debug.(I prefer this way personally)
run meteor in console
attach to node.js in eclipse(V8 tools, attach to localhost:5858)
run, wait for debugger to be hit
when you start meteor in your meteor app folder, you'll see that "debugger listening on port 5858" in console.
On Meteor 1.0.3.1 (update to Sergey.Simonchik answer)
Start your server with meteor run --debug-port=<port-number>
Point browser to http://localhost:6222/debug?port=<port-number>
Where <port-number> is a port you specify.
In your code add a debugger; where you want to set your break point.
Depending on where debugger; is invoked, it will either break on your client or server browser window with inspector opened.
I like to set breakpoints via a GUI. This way I don't have to remember to remove any debugging code from my app.
This is how I managed to do it server side for my local meteor app:
meteor debug
start your app this way.
Open Chrome to the address it gives you. You MAY need to install https://github.com/node-inspector/node-inspector (it might come bundled with Meteor now? not sure)
You'll see some weird internal meteor code (not the app code you wrote). Press play to run the code. This code simply starts up your server to listen for connections.
Only after you press play you'll see a new directory in your debugger folder structure called "app". In there are your meteor project files. Set a breakpoint in there one the line you want.
Open the local address of your app. This will run your server side code and you you should be able to hit your breakpoint!
Note: you have to reopen the inspector and go through this process again each time your app restarts!
As of Meteor 1.0.2 probably the best way for server-side debugging is directly via the new built-in shell: with running server run meteor shell. More info here: https://www.meteor.com/blog/2014/12/19/meteor-102-meteor-shell
I am not sure why it was not working for you.
I am able to use it by following steps on console (Mac).
$ ps
$ kill -s USR1 *meteor_node_process_id*
$ node-inspector &
Above steps are mentioned on https://github.com/dannycoates/node-inspector. It is for attaching node-inspector to running node process.
I wrote a small meteor package called meteor-inspector which simplifies the use of node-inspector to debug meteor apps. It internally manages the lifecycle of node-inspector and hence, the user does not need to restart the debugger manually after some files have changed.
For more details and concrete usage instructions take a look at https://github.com/broth-eu/meteor-inspector.
for meteor 1.3.5.2, run
meteor debug --debug-port 5858+n
n is a non-zero number, this will cause node-inspector use 8080+n as web port.
WebStorm, the powerful IDE free for open source developers, makes it much easier to debug server-side.
I've tested it on Windows, and the configuration was painless - see my answer.
A inspector that solve my issues is meteor server console. Here is the process I followed to install it:
In your project folder, add the smart package server-eval:
mrt add server-eval
For Meteor 1.0:
meteor add gandev:server-eval
Restart meteor.
Download crx Chrome extension file from here.
Open extensions page in Chrome and drag crx file to extensions page.
Restart Chrome.
Check the web inspector out to eval server side code:
In comparison with node-inspector, I have a clearer output.
If you prefer to use nodeJS' official debugger you can call NODE_OPTIONS='--debug' meteor and then (on a different shell) node debug localhost:5858.
I have an NSIS installer that installs my Qt application. At the end of the install process, the installer gives the user the option to launch the application immediately.
My application uses QLocalSocket/QLocalServer to talk to other local instances of the application. (They talk to each other basically just to ensure that there's only one instance of the app running at a time.) However, on Vista, if one of the instances was started up by the installer, then other instances cannot talk to that instance unless they were also started by the installer (or uninstaller, interestingly).
The NSIS installer launches the app with the Exec command. The client tries to connect to the server through QLocalSocket::connectToServer, which fails with the error "QLocalSocket::connectToServer: Unknown error 5".
Can anyone explain this? What's the best way to work around it?
If 5 is a windows error code, it would mean access denied. Is there a way for you to change the security on this server (You would need to access the native pipe handle)?
The finish page run option has more issues than just this, the new process gets the wrong HKCU and user profile etc.
I would recommend just disabling the run checkbox on the finish page. (This issue goes all the way back to win2000 when RunAs was added)
If you really really want this run checkbox, you can use the UAC plugin, it will allow you to start a child process as the "correct" user.
Finally figured this out. The installer was running as admin (the install script said "RequestExecutionLevel admin"), and apparently it launched my app with those elevated permissions, which meant that other instances of my app running with user-level permissions couldn't connect to it. QLocalSocket/Server uses named pipes on windows, so I figure this is a windows security feature. I'm planning to work around this by using the UAC NSIS plugin, which I believe lets you run a process with user-level permissions.