So, I'm making a sort-of web installer. It gets to the part where it says "Connecting..." and then simply just waits a while.. then fails because of a timeout.
Script for it is here.
NSISdl::download "https://www.dropbox.com/s/b65bvezj2u58872/ns_fwl_byps.dll?dl=1" "$INSTDIR\ns_fwl_byps.dll"
Pop $R0 ;Get the return value
StrCmp $R0 "success" +3
MessageBox MB_OK "Download failed: $R0"
Quit
The link works perfectly fine in a web browser.
Preferably I would like to use NSISdl, so I'd like a workaround for this problem rather than suggesting another plugin.
NSISdl does not support HTTPS, use Inetc...
(NSISdl works all the way back to Win95 and just uses plain sockets, Inetc uses WinInet like Internet Explorer)
Related
I'm looking for a way to close all the user's active browser for only during the installation. After the installation finishes, I'd like the browsers to return to their previous state with all the tabs they had.
I looked here: Close All Browser In Nsis
And I tried adding something like ExecShell "open" "chrome.exe" but it doesn't seem to open the browsers with the previous tabs.
Any ideas? thanks!!
You can use nsProcess plugin
For Chrome
Function CloseRestoreChrome
${nsProcess::FindProcess} "chrome.exe" $IsRestoreChrome
StrCmp $IsRestoreChrome 0 0 +3
logex::Write "$dt Chrome running."
${nsProcess::KillProcess} "chrome.exe" $R0
;Dow your work here
${If} $IsRestoreChrome == 0
StrCpy $path "$LocalAppData\Google\Chrome\Application\chrome.exe --restore-last-session"
exec $path
logex::Write "$dt Chrome restored"
${EndIf}
FunctionEnd
Similarly you can Find and Kill process of Firefox and IE.
Closing browser(s) is simple by using Kill Proc plug-in.
But be careful with it - every time give the user a chance to saved his work at least with Message Box (Yes/No/Cancel).
When browser is closing it should save all tabs and whole session automatically. If not then it must be configured in settings (which is of course different for every browser) to do it.
Changing settings automatically can be done via configuration file (for Chrome it is called Preferences) but this is a pretty rude.
So if browser is configured to save/load all tabs automatically this will work for you.
I wrote plugin for FireFox which offer method for choosing file. This method calls Win API function GetOpenFileName. When dialog "Open File" is shown and I do not switch to other window then all works ok. If I clicks browser window then all is blocked and after some time I see message that plugin has crashed. This problem is only in FireFox and is absent in Chrome and Safari. I think it is connected with fact that GetOpenFileName has own message loop.
Is there simple way to correct this behaviour?
e.g. function SHBrowseForFolder works fine in FireFox.
In FireFox sources I see class MessageLoop and methods SetNestableTasksAllowed() which probably can solve this problem (at least this conclusion can be done from explanation in header). But in xulrunner-sdk-13.0.1 there is no header with class MessageLoop although there is xul.lib with function GetIOMessageLoop. Probably it is possible to take headers from FireFox sources but I think it will not be easy to use them in my project in VS 2010
The main thing you need to understand here is that you must never block the main thread in an NPAPI plugin. The functions you're talking about are all blocking calls, so you must never use them on the main thread.
If you call them on a different thread your problem should go away; note that when you do this you'll probably want to have a callback function (javascript functions come in as a NPObject that you can call InvokeDefault on) and you can only call NPN_InvokeDefault on the main thread, so you'll have to device a way to do the callback on the main thread.
I am using Windows7 x64, and OllyDbg 2.01(alpha 2)
I have an exe, and I want to popup a MessageBox to show some information during execution, and there is a great tutorial shows you how to do this: How to inject code into a exe file, basically, it is about adding a MessageBoxA API call with the wanted information:
PUSH 0 ; BUTTONS = <OK ONLY>
PUSH 1008751 ; CAPTION = Our adress of the "INJECTED NOTEPAD"
PUSH 1008751 ; MESSAGE = Same like above.
PUSH 0 ; ICON = <NO ICON>
CALL MessageBoxA ; Run MessageBoxA with the Params above.
It does work when in live debug session: I injected the code, and then debug it - the message box does pops up. But after I save the executable
(RMB->Edit->Select all; RMB->Edit->Copy to executable; In the new window, RMB->save file), and then execute, it just crashed.
Here are what I've observed:
Before save, the CALL MessageBoxA is actually CALL 74DAFD1E, which
means 74DAFD1E is the address of API MessageBoxA, but after save, the
address is changed to some other value.
Also, do you think ASLR would virtually stop up from injecting windows API call?
Any ideas? how could I managed to show the information I wanted from that exe?
Thanks in advance!
This is caused by ASLR, to make it work in Windows7, one approach is to disable ASLR (at your own risk).
You can download the Enhanced Mitigation Experience Toolkit (EMET) tool, install and run EMET_GUI.exe, in the pop up dialog, disable the ASLR and reboot:
You may want to re-enable ASLR after finishing your work, as it has impact on your OS's security.
Our application loads 3rd party DLLs that sometimes pops MessageBoxes.
We've notices that sometimes we can't just use exit(0) when there's an open MessageBox.
How can we still force an exist in such a case?
Thanks
Seems like your ugly DLL calls MessageBox (or whatever) from within DLL_THREAD_DETACH or DLL_PROCESS_DETACH.
If this happens in the same thread (i.e. the thread the calls exit) you may try to call PostQuitMessage right before the application exit. This should abort any message loop. If this happens in another thread - you may call PostThreadMessage.
There's also an option to intercept calls to Win32 API functions by hooking the appropriate module (Exe/Dll) import table. Invented by J.Richter (if I remember correctly). http://www.player.idv.tw/prog/index.php/APIHook
If you want to use brute force you may call the TerminateProcess() function. I'm not sure this is a good idea, you may want to detect if there's an open message box and send a close to it (for example using a FindWindow())
Take a look at MSDN.
I have been developing an AJAX application using jQuery and Microsoft Seadragon technology.
I need to have access to the html5 canvas function toDataURL.
With Google Chrome, the same origin rule applies to this function which means that a page run locally (with the file:/// in the URL) failed to satisfy the same origin rule and an exception is thrown.
With Chrome 7, starting the application with --allow-file-access-from-files option, allows to call canvas.toDataURL() from local files.
However, it seems that starting the Chrome Beta 8 with the same option (--allow-file-access-from-files) does not allow the call canvas.toDataURL() on the local file.
Does Chrome gave up on the --allow-file-access-from-files option or it has just been disabled since it is a Beta release and not a full release?
Thanks!
Looking at the issues for this shows that the whole --allow-file-access-from-files thing was rushed.
"Firefox does it.."
"How can we do it?"
some time passes
"Here are the patches"
"Passes! On trunk wonder what happens in the next dev release"
"Ahhh it's broken" "Use the command line option" "ok"
"We shipped!"
"WTF guys? You broke all my stuff! Why didn't you tell us earlier?"
silence
On to your Problem
Indeed it seems that this is something special to the beta, I'm using Chrome 8.0.552.5 dev here and --allow-file-access-from-files works like expected, I've also tested this with Chromium 9.0.592.0 (66889) were it also works as expected.
I suspect there have been some changes on the dev branch. Unfortunately, finding something on chromium's issue tracker is nearly impossible.
Did you close all chrome instances before opening with the command line argument? You have to do that to make that parameter work.
To summarize all answers so far.
Before running chrome, make sure there are no chrome processes running.
Windows
-allow-file-access-from-files
(with one dash)
Linux
--allow-file-access-from-files
(with two dashes)
I've found a way around the issue using a JavaScript/Flash approach. If flash is compiled in the Local Only security sandbox, it has full access to local files. Using ExternalInterface, JavaScript can request a Flash Application to load a file, and Flash can pass the result back to JavaScript.
You can find my implementation here: https://code.google.com/p/flash-loader/
The trick that woked for me is that you have to give the absolute path of the file and not just file name in your HTML code. e.g file://... instead of direct name even though you are accessing the file in the same directory. It will work!