I would like to run my own executable binary file (generated from C code) bundled along with other regular files in my Firefox add-on. Since, it needs to create a new process for that, I think I should use either sdk/system/child_process or a native OS API by using js-ctypes.
My question is that does creating a new process have any negative impact on the add-on publishing process? Does it violate any Mozilla's rule?
Creating a new process has a severe impact on the add-on publishing process but it does not violate the rules.
By interacting with the system in such a low-level way, your add-on will be flagged for administrative review which can result in even trivial updates taking up to 3 months to be approved. It certainly won't always take that long (and the reviewers are very good at rushing through reviews which fix critical or security impacting bugs if you explain the mitigating circumstances to them) but for a typical new version it can be months between submitting the XPI file for review and it actually being delivered to users.
At the moment you can avoid that delay by hosting your add-on outside of the AMO ecosystem but that will change in the next 1-2 months when the add-on signing requirements come into play. They say that the reviews for non-hosted add-ons will be faster and I hope that this will be the case but even so, the need for a manual review might be a serious problem if you're looking to get a regular automated test and deployment process in place for your add-on.
I wouldn't be surprised if Mozilla make further changes in this area later in the year in order to stem the loss of their add-on developer community. In particular, it seems crazy that even unchanged code will trigger the need for a review for every minor update.
As for how you go about implementing it, I've not used the SDK before so your suggestions are probably best but a third option to consider is the use of the XPCOM nsIProcess interface. I don't use ctypes in my add-on any more but I would expect that to be flagged for admin review in the same way as any other approach that could feasibly launch an executable.
As far as the bundling is concerned, that shouldn't be a problem but you will need to supply the source code to Mozilla so they can ensure it is safe.
Related
Recently I've been trying apktool but I wonder what is the use of reverse engineering/rebuilding an APK with a tool like apktool? I've already searched it but I didn't find the answer
You'll find different reasons for many people.
Static analysis - Investigating an application for an audit, looking for malicious behavior or running analytics at scale against large collections of applications. It is easier to query an application disassembled via Apktool (at times) then talking directly to a compiled APK.
Automation - Before the constant improvements to tooling in the Android space, it was quite favorable to rename a package name through Apktool. This may be part of a build process to make a quick "test" application with security enhancements disabled to make debugging/logging easier.
Reverse Engineering - See how something works, take apart a malware sample. The possibilities in this category are quite broad.
Translation - Lots of applications are built from afar and some folks are interested enough in ROMs, Apps and more to make them usable for their culture/language. A simple disassemble and rebuild with newer language files and the application is translated.
Tweaking - At times an application is almost perfect for an individual. They don't trust updates and want to make a quick change to an application and run it themselves without poking around in assembled files.
Abuse - Taking paid features out of paid applications and rehosting them. Not happy about this one, but can't ignore it happens
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
I have used InstallAware and InstallShield before, and they are pretty difficult to work with and when something goes wrong it is very difficult to find and resolved the issue.
My question is why can't we use a Windows application written using C# to do this.
I understand that .Net framework may not be installed on the destination computer, so I wonder why no one has ever used this architecture:
I will create a simple installer using IntallSiheld(or any other similar tool) to just install .Net Framework and after that extracts and runs my own Windows application which I have written using C# in elevated mode. My application will run a Wizard with Back and Next button and I will take care of everything in it (copying files, creating and starting Windows Services, adding registry values, creating firewall extensions etc.)
Has anyone ever done this, and is there anything that prevents people from doing this?
In essence: don't try to re-invent the wheel. Use an existing deployment tool and stay with your day job :-). There are many such tools available. See links below.
And below, prolonged, repetitive musing:
Redux: IMHO and with all due respect, if I may say so, making your own installer software is reinventing the wheel for absolutely no gain whatsoever I am afraid. I believe you will "re-discover" the complexities found by others who have walked the path that is involved in deployment as you create your own installer software and find that software can be quick to make, but very hard to perfect. In the process you will expend lots of effort trying to wrap things up - and "the last meter is very long" as you curse yourself dealing with trifles that take up your time at the expense of what would otherwise pay the bills. Sorting out the bugs in any toolkit for whatever technical feature, can take years or even decades. And no, I am not making it up. It is what all deployment software vendors deal with.
Many Existing Tools: there are many existing tools that implement such deployment functionality already - which are not based on Windows Installer (Inno Setup, NSIS, DeployMaster and heaps of other less known efforts):
There is a list of non-MSI installer software here.
There is another list of MSI-capable software here.
My 2 cents - if you do not like MSI, choose one of the free, non-MSI deployment tools. How to create windows installer.
Corporate Deployment: The really important point (for me) is that corporate deployment relies on standardized packaging formats - such as MSI - to allow reliable, remote management of your software's deployment. Making your own installer will not impress any system administrators or corporate deployment specialists (at least until you sort out years of bugs and deficiencies). They want standardized format that they know how to handle (that does not imply that they are that impressed with existing deployment technology). Doing your deployment with standardized deployment formats can get you corporate approval for your software. If you make a weird deployment format that does unusual things on install that can't be easily captured and deployed on a large scale your software is head-first out of any large corporation. No mercy - for real. These are busy environments and you will face little understanding for your unusual solution.
"File-Pushers": Those of us who push files around for a living know that the field of deployment is riddled with silly problems that quickly kill your productiveness in other endeavors - the ones that make you stand out in your field - your day job. Deployment is a high profile, low status endeavor - and we are not complaining. It is just what it is: a necessity that is harder to deal with than you might think. Just spend your time more wisely is what I would conclude.
Complexity: Maybe skim the section "The Complexity of Deployment" here: Windows Installer and the creation of WiX. It is astonishing to deal with all the silly bugs that happen in deployment. It is not just a file copy, though it might be easy to think it is. And if it happens to be just a file copy, then there are existing tools that do the job. Free ones too. See links above. And if you think deployment is only file-copy in general, then please skim this list of tasks a deployment task should be capable of supporting: What is the benefit and real purpose of program installation?
Will your home-grown package handle the following? (just some random thoughts)
A malware-infected terminal server PC in Korea with Unicode characters in the path?
Symbolic links and NTFS junction points paths?
A laptop which shuts itself off in the middle of your file copy because it is out of battery?
Out of disk space situations? What about disk errors? And copy timeouts?
What about reboot requirements? For in-use files or some other reason. How are they to be handled? What if the system is in a reboot pending state and you need to detect it before kicking off your install?
How will you reliably install, configure and start and stop services?
How will you support uninstall and cleanup for your application?
Security software which flags your unknown, unrecognized, non-standard package a security threat and quarantines it? How would you begin to deal with this? Who do you contact to get into the good graces of a "recognized binary" for elevation?
Non-standard NTFS permissioning (ACLs) and NT Privileges? How do you detect it and degrade gracefully when you get permission denied? (for whatever reason).
Deployment of necessary runtimes for your application to work? (has been done by many others before). Download of the lastest runtimes if your embedded ones are out of date? Etc...
Provide a standardized way to extract files from your installation binary?
Provide help and support for your setup binaries for users who try to use them?
Etc... This was just a random list of whatever came to mind quickly. There are obviously many issues.
This was a bit over the top for what you asked, but don't be fooled to think deployment is something you can sort out a solution for in a few hours. And definitely don't take the job promising to do so - if that is what you are being asked. Just my two cents.
The above issues, and many others, are what people discover they have to handle when creating deployment software - for all but the most trivial deployments. Don't waste your time - use some established tool.
Transaction: If you are working in a corporation and just need your files to your testers, you can deploy using batch files for that matter - if you would like to. But you have to support it, and I guarantee you it will take a lot of your time. What do you do when the batch file failed half-way through due to a network error, and your testers are testing files that are inconsistent? Future deployment technologies may be better for such light-weight tasks. Perhaps the biggest feature of a deployment tool is to report whether the deployment completed successfully or not, and to log the errors and to roll the machine back to a stable state if something failed. Windows Installer does a lot of this work for you.
Distribution: A lot of people feel they can "just replicate my build folder to the user's computers". The complexities involved here are many. There is network involved, and network can never be assumed to be reliable, you need lots of error handling here. Then there is the issue of transactions: when do you know when the computer is in a stable state and should stop replicating. How often do you replicate, only on demand? How do you deal with the few computers that failed to replicate. How do you tell the users? These are distribution issues. Corporations have huge tools such as SCCM to deal with all these error conditions. Trying to re-implement all these checks, logging and features will take a long time. In the end you will have re-created an existing distribution system. Full circle. And how do you do inventory of your computers when there is no product registered as installed since only a batch file or script ran? And if you start replicating a lot of packages, how many times do you scan each file to determine if they are up to date? How much network traffic do you want to create? Where does it end? The answer: I guess transactions must be implemented with full logging and error tracking and rollback. Then you are full circle to a distribution system like I mentioned above and a supported package format as well.
This "just replicate my build folder to my users" ideas somehow remind me of this list: https://en.wikipedia.org/wiki/Fallacies_of_distributed_computing. Not a 100% match, but the issues are reminiscent. When networking is involved, things start to become very unpredictable and you need logging, error control, transactions, rollback, network communication, etc... We have re-discovered large scale deployment - the beast that it is.
Network: and let's say you want to replicate your build folder to 10000 desktop machines in your enterprise. How do you kick off the replication? Do you start all replications at once and take down the trading floor of the bank as file replication takes over the whole network like a DDOS attack? Sorry - it is getting out of hand - please pardon the lunacy - but it really is upsetting that this replication approach is seen as viable for large scale deployment with current technology approaches. Built-in Windows features could help, but still need to be tested properly. You need scheduling, queuing, caching, regional distribution shares, logging, reporting / inventory, and God knows what else that a packaging / deployment system gives you already. And re-implementing it will be a pain train of brand new bugs to deal with.
Maybe we one day will see automatic output folder replication based on automatic package generation which really works via an intelligent and transacted distribution system. Many corporate teams are trying, and by using existing tools they get closer with standard package formats used. I guess current cloud deployment systems are moving in this direction with online repositories and easy, interactive installation, but we still need to package our software intelligently. It will be interesting to see what the future holds and what new problems result for packaging and distribution in the age of the cloud.
As we pull files directly from online repositories on-demand we will see a bunch of new problems? Malware, spoofing and injection? (already problematic, but could get worse). Remote files deleted without warning (to get rid of vulnerable releases that should no longer be used - leaving users stranded)? Certificate and signature problems? Firewalls & proxy issues? Auto-magic updates with unfortunate bugs hitting everyone immediately and unexpectedly? And the fallacies of the network and other factors as linked to above. Beats me. We will see.
OK, it became a rant as usual - and that last paragraph is heading over board with speculation (and some of the issues already apply to current deployment). Sorry about that. But do try to get management approval to use an existing packaging & deployment solution is my only advice.
Links:
Stefan Kruger's Installsite.org twitter feed: https://twitter.com/installsite
Choosing a deployment tool:
How to create windows installer
What installation product to use? InstallShield, WiX, Wise, Advanced Installer, etc
Windows Installer and the creation of WiX
WiX quick start tips
More on dark.exe (a bit down the page)
I was wondering if you guys know of any software that allows me to jot down notes in a project based environment, as well as enabling me to track bugs or other issues in OSX. Basically, I have a lot of little projects on the go, and I would like to have one place where I can store and organize all their information. I have done lots of research on issue tracking systems, but they all seem to be overkill for what I need. I essentially need just a single user desktop application were I can enter bugs for myself to view later. So far I have basically been doing this with sticky notes/other such applications, but I think its time for a step up to an application that stores the history of bug fixes, open issues, etc. Any ideas? Thanks beforehand!
I know you mentioned desktop, but from reading your question I would recommend Trello http://www.trello.com.
Trello is really nice for keeping track of small to medium projects and does not take up all of your time when entering in steps.
I'm a freelance web developer working on multiple projects. Earlier I used to use small applications to keep track of project tasks. Now that the number of projects have increased, I've been using Microsoft Project Professional. The project management software ensures that I can test, report, and track all my project tasks. This helps me be in sync with project progress.
We were searching for a simple bug tracking solution too and found some pretty cool platforms like Instabug, BugSee, ... The problem was that they are pretty expensive, so we developed a new platform that's made for everyone. BugBattle.
https://www.bugbattle.io
It offers something that's called in-app bug tracking, which allows you to report bugs (+ all kinds of useful information like screenshots, meta data about devices, ...) directly within your app. It's super easy & fast to integrate. I takes about 2 minutes or so to integrate it within your websites, apps, webapps. Def. worth trying.
In addition we added features like the BugBattle Challenge, which enables you to basically fight against others in bug fixing challenges. Haha, it should be fun to fix bugs :)
i'm facing a challenge of rebrushing and updating an almost 10-years old Screenweaver project, and looking for a decent modern swf-exe convertor. Don't have much time to evaluate all the options, therefore i'd like to hear responses with actual working experience with such a tool.
Since WinAPI interaction is a must, the default projector is not an option.
Similar questions (no concrete answers there)
Package SWF into an EXE or APP
Create an EXE from a SWF using Flex 3 without requiring AIR?
Many thanks
UPD: 300 bounty for anyone who can help me with a practical answer.
I've been experimenting with different SWF projectors for a long time now, and so far I think I've tried most if not all of them. I've explained in more detail the best projectors I have used below.
MDM Zinc
http://www.multidmedia.com/software/zinc/
I remember back in when I had Vista that MDM had quite a few bugs running under that OS. It took a while for them to fix those bugs - the bugs didn't stop it from running, but really interfered with the functioning of some methods in the program. For this reason, I decided not to continue testing Zinc and moved on to another projector. Saying that though, I'm certain they have fixed those bugs now.
The program itself has a nice intuitive interface, and allows you create screensaver as well as EXEs (which is obviously good for you).
The product is pricey - currently at $349.99, so this put me off.
You can also generate Mac and Linux projectors which is very attractive, but requires an additional license for each which does cost a lot of money.
SWF Studio
http://www.northcode.com/
This was one of the projectors I really enjoyed working with. It's fully featured, has great community support and the developers are always on hand to help. The projectors it generates are compatible with all Windows operating systems, and I've never had any problems with bugs on this one.
Northcode also offer a student license for SWF Studio for $49. I nearly purchased a license with these guys but the only reason why I didn't was because I found another projector which was better for my scenario which I will come onto in a moment.
I can tell you that one of the reasons why I didn't use this projector (it does sound trivial) is because it had a large file size. SWF Studio allows you to select what size projector you want in terms of filesize - with options like tiny and compact I think but the smaller file types might have dependencies with other files in the directory. This means that you would have to bundle your application with some folders and additional files as well as the EXE itself.
SWF Studio also has the option to create screensavers.
mProjector
http://www.screentime.com/software/flash-projector
mProjector has gone up a version (from 3 to 4) since I last used it, so it may incorporate a lot more features in this version. I remember that the product is very good with transparency, and showcases some 'screen buddies' which use transparency to virtually walk about your screen. The reason why I didn't use this projector is because it didn't have as many Actionscript functions as I would have liked, but I believe it has a lot more nowadays. In your project this wouldn't be so much of a problem because you want a screensaver.
It is reasonably priced at $399 for both Windows and Mac compatibility, but you can buy just Windows or Mac if you wish for a cheaper price.
Janus Flash
I was going to explain this product in more detail but I have now realised that the website no longer exists! Janus is the projector I liked the most and ended up using because of the sheer amount of features available for use in your code.
Like all the projectors I have mentioned above, each one adds functionality to flash which you don't usually get with an SWF. Each product includes pre-built actionscript methods which can interface with the operating system itself to do things you can't do in the Flash sandbox. For example, each one of these projectors allows you to manipulate files (add, edit, delete e.t.c.) on the computer. Janus had the most methods available out of all the projectors I tried. This is partially because Janus used the .NET framework (which meant that .NET 2.0 was required on the system you were executing the projector on).
Also like MDM Zinc, this product allowed you to create applications for the Mac too. I managed to get a cheaper price too when I contacted them directly explaining that I was a student. I recently contacted Janus-Flash to ask about the future of the product, and they said that they may re-release Janus in the future, but for now it's off the market.
Some other products I have used which are worth a mention but I haven't explained in detail: SWFKit, Jugglor, F-IN-BOX (more developer releated as it required cutting code).
A quick search brings up these which might be worth a look: Flash2Me, Flash EXE Builder and SWF to Screensaver.
For your project I think the best option would be SWF Studio. It has lots of nice scripting features you can use to interface with the OS, and is nicely priced too at $299 for a full license.
I hope this helps in your decision for what projector to use, and will save you from trying out many different projectors like I did over several months!
We support a lot of Win32 functionality directly in our core API so chances are you may not even have to make a direct API call, but if you do...
SWF Studio has an advanced Plugin API that allows you to write custom plugins in C++, C# or VB.NET so you can call win32 or .NET functions. We created our own ummanaged to managed code shim so you can write a native .NET plugin and call it from SWF Studio just as easily as you can write a Win32 plugin.
There's no difference between how you call a SWF Studio function in AS2 or AS3. We have maintained 100% backward compatibility in our API. Whether you're using AS2 or AS3, your calls will just work. And they'll continue to work.
However, the place we really shine is support. I created SWF Studio and I'm still in the forums EVERY day answering questions and fixing bugs.
My experience here is from a year ago.
Having worked with mProjector I can tell you that the AS3 API is quite robust and easy to use. I was able to wrap a large swf-based project using external assets up into an EXE without a lot of problems. The UI for mProjector's project gui leaves something to be desired, but the actual hooks to the file system were easy to use.
The difficulty is that not all of it is documented. In fact there were as of a year ago a lot of undocumented packages.
My only real problem with mprojector was that in AS3 there wasn't any support for SharedObjects. Someone in their community worked around this and made their solution available. It does of course make use of storing a file on the local system.
This overall compared favorably against Zinc which was extraordinarily complex, slow to compile, and worse than having no documentation all the docs I needed were flat-out wrong.
I ruled out Jugglor almost immediately. It never successfuly compiled anything.
Since this is an old project you're talking about, and written in AS2, I can't speak to that side of it. I can say however that programs like Zinc and mProjector have been around a lot longer than AS3 has, and that the same hooks that are available in AS3 seemed to be available in AS2 also. The possibility exists that there may be more such hooks in AS2 since it's been supported for longer, but I cannot vouch for this at all.
I have used all of these applications, but most of all I liked theFlajector - a program that converts flash movies (swf) to exe files. You can include a flash player in generated applications and they will use it. In other words, the applications will work even if no flash player is installed. Also, Flajector can create windowless applications from flash movies. You can extend your applications using plugins. Using standard classes you can work with files and more.
I'm looking at getting a FireFox plugin developed - but is it possible to create a plugin that is for private use only, so only those I share it with have it and not open to the masses? Need this for 2 reasons; 1) while in BETA and 2) for my clients use only to start with.
Of course: just distribute the plugin install package (XPI if I am not mistaking) to the target users.
Note that won't prevent leaks, if any.
You could also be more fancy and "lock" the plugin to a set of computers: you have access to the whole machine when you design a plugin (e.g. NPAPI based). Then again, a determined hacker can always find a way.
Yes, of course this is possible.
Extensions (mentioning these because the term "plugin" is often misused to mean "extension") can be packed in a .xpi file that can be opened and installed by Firefox; see also this tutorial.
Proper plugins are a bit more work, see the Mozilla developer wiki.
While this works mostly on a psychological level, prominently displaying identifying information such as the user's name/email address or a company name/logo, may also help prevent users from distributing your work because it is obviously personalized/tailored software, and they may not want this information to be distributed along with your software.
Also, once you do distribute your extension to your target users, you can digitally sign the XPI files for each individual user (i.e. fingerprinting individual files within the XPI package), so that you can track back any leaks.
In addition, you as the author of the extension are of course free to implement a simple "talkback" mechanism so that you can track use of your extension, along with all sorts of other information that may be relevant to you (i.e. usage stats).
Similarly, XPI files are conventional ZIP files, so you can also password-protect them to make it more complicated to install them without proper instructions.