I've just read this paper which presents the BSDiff tool as a method to diff-and-patch binary files. I wonder whether these types of tools are good and suitable in systems which can't afford any kind of error in this process.
I'm working in an embedded project and we are looking for ways to update the bootloader image without transferring the whole new version, but only small pieces. The binary image that we want to update, encompasses not only the application we've developed but also the OS (FreeRTOS) and third party libraries.
Try this implementation of BSDiff:
https://github.com/Cheedoong/bsdiff
Cross-platform, and with no dependency on other library.
Related
This is probably not a simple question so I am not looking for a definite answer but just some pointers to get me in the right direction.
I have absolutely no experience with C/C++ but have good knowledge of Objective-C. I also don't know much about different compilers and architectures so please be nice if I am talking stupid :)
I have some MatLab code that needs to be ported to Objective-C to run on an iPhone application. My first tentative path to get this done would be to check if MatLab can export the code as a static C/C++ library that I can call from within my Objective-C code.
This seems to be the case but I am not entirely sure what to do next, and what things I need to keep in mind when compiling the library on the MatLab side (i.e. architecture, compatibility, PC vs Mac, etc).
I have been provided with a .DLL and .LIB files which I believe are Windows compiled so they will not be useful for me, is this correct? From working with previous static libraries I can see they all have a .a extension - what do I need to do to get one that is compatible with the iPhone architecture?
And once I get the library compiled, how to I import and use it within my project? Will I just be able to call the public methods directly from within my code?
What else do I need to know or be aware of?
Any help is very much appreciated!
Thanks,
Rog
Static libraries contain binary code tailored for some specific operating system and platform. That means that it will use the OS to internally acquire memory (if it uses dynamic memory) or to perform any other OS specific operation (logging, output).
Even if the generated code was completely OS-agnostic (basic math could be implemented without OS support), the platform is completely different, matlab will generate code for an intel platform and the iPhone runs in an ARM architecture, with a different instruction set calling conventions...
Unless matlab is able to generate static libraries for the iPhone or at the very least for an ARM platform and make it OS-agnostic, you are out of luck.
I have minimal exposure to RPM, Windows installer mechanics, and WIX. That said, I'm interested in making a cross-platform installer tool (Linux, Windows) that supports upgrading and downgrading (versiona and patches) of my own product. I don't believe this is a topic to be approached lightly; I would like to learn the science of the art (or the art of the science). If I succeed, and build a minimally successful installer tool, it would have these features:
does not depend on a platform-specific tool (such as Windows Installer).
reads XML or a declarative syntax to fulfill installation requirements.
attempts to minimize steps to upgrade or downgrade one of my products (rather than requiring a complete uninstall and re-install).
does not require knowledge of interim product versions, in order to jump versions (i.e. can upgrade one of my products from version 1 to version 3, without passing through version 2).
I'm convinced that "the key" to achieving this goal is by seeing versions as a "point A to point B" problem, which implies that A and B are described by two XML "version" documents that hold info about all the parts and actions (files, or platform specifics such as registry entries). My installer tool would "join" or compare the two documents and determine a minimal set of changes to transform A into B. To some extent, I believe this is precisely what Windows Installer does.
Of course there are further complexities, but that is the point of this post. Where is "the bible" of information on this topic? Remember, I want to make my own installer - not use a platform-specific one. For those who care, my products are usually written in C++ or C#.
Or perhaps I should study something like Steam which is cross-platform and has "automated game updates" as part of its capabilities. In my case, the problem of online deployment is already handled. It is just the final installation step I'm examining. Does Steam use native installers (such as an MSI)? If yes, then that is not what I'm looking for.
In short, what path should I pursue to become somewhat competent on the science of this topic?
I'm not an expert and others can give you better answers but...
Don't declaratively list steps required to install your product - You'll end up making assumptions which will eventually prove wrong. Instead, you should be looking at defining the final state of the installation and let the installer worry about how to make that happen.
Another consideration is that being downgradable may involve huge complications depending on your product - Would it have to down-grade database schemas / file formats / ??? In short, every version of your app will need to be both fully forwards- and backwards-compatible (or at least fail gracefully). Also consider the scenario where V1 of your app stores settings in a file. V2 comes along and adds more settings. You downgrade to V1 - What should it do when changing settings? preserve the V2 settings? dump them? Do some of the V2 settings change the impact/meaning of the V1 settings? Are these decisions to be made by your app or your installer?
Anyway, all that aside, I'd say you need at the least:
A central server/farm with complete files for every version of your App and some API/Web Service which allows the installer to retrieve files/filesets/??? as appropriate (You may be able to tie this into a source control system like svn)
Some way of specifying the desired post-install state of the system in an environment-agnostic way (Think install paths - /usr/??? - should the map to C:\Users\??? or C:\Program Files on windows? Also don't forget it might be a 64-bit machine so it could be C:\Program Files (x86).
A very clever installer written for multiple platforms with as much code re-use as possible (Java, Mono, ???)
The installer should do (simply):
Determine the desired version of the product.
Download/read the appropriate manifest.
Compare the desired situation with the current situation (NB: What is currently on the local system, NOT what should be on the system according to the current version's manifest)
Generate a list of steps to reconcile the two, taking into account any dependencies (can't set file permissions before you copy the file). You can make use of checksums/hashing/similar to compare existing files with desired files - thus only downloading the files actually required.
Possibly take complete backups
Download/unpack required files.
Download/unpack 3rd party dependencies - Later .Net Framework Version/Similar
Perform install steps in atomic a manner as possible (at the very least keeping a record of steps taken so they can be undone)
Potentially apply any version-jump specific changes (up/down-grade db, config files, etc.)
verify installation as much as possible (checksums again)
None of this addresses the question of what to do when the installer itself needs upgrading.
A technique I've used on Windows is that the installer executable itself is little more than a wrapper with some interfaces which loads the actual installer dynamically at runtime - thus I can move files about/unload/reload assemblies, etc... from within a fixed process that almost never changes.
As I said above, I am definitely not an expert, just a novice who's done some of this myself. I sure you can get more complete answers from others but I hope this helped a little
It's very slick and cross browser/platform at the click of a button, which is leading non-technical types to conclude the entire engine is intrinsically better than what we use now. Is it simply that they've taken the time to implement all the per-browser/OS plugin versions of Unity WebPlayer and polish it, or is there anything deeper in the way the engine architecture is set up?
Unity takes scripts written in C#, UnityScript (based on JavaScript), or Boo (based on Python), and compiles them into mono assemblies. Those assemblies + the 3d models, sounds, and textures required by your game are compressed into a .unity3d file that is loaded by their browser plugin. Since almost all of the game's logic is in managed mono assemblies it runs cross platform with very few platform specific quirks.
They've recently rewritten their plugin detection and installation code so that it is very easy to drop a block of javascript into a web page that shows Unity content if the user has the plugin, or other content (image, flash, video) if they don't. I believe their plugin supports all A-class browsers on Mac and Windows, and the plugin can be installed without restarting the browser.
One advantage of the Unity engine is that you can take a lot of off-the-shelf managed assemblies and include them in your project and call them from Unity code. But you have to be aware that these assemblies can really bloat the size of the .unity3d file.
Another advantage is that you can easily write components that expose tunable parameters that can be modified by non-technical people.
And yet another advantage is that a well written project can be ported to/from iPhone, Standalone, Android, Web, etc. in under a day. I've personally done iPhone to Web by just modifying my input handler and changing texture compression.
One big disadvantage is that since the application is running managed code it is not too difficult for a curious or malicious person to decompile the assemblies into completely readable code. So you need to think about what someone could do with that info (cheat in multiplayer, write bots, falsify high scores, etc.). It is possible to obfuscate your assemblies, but it isn't trivial to add this step to your build process.
I'm trying to write an SSH client for the iPhone, and I'd like to use the libssh2 open source library to do so. It's written in C.
How should I include this C library for my iPhone app? Should I compile it into some binary that I include into the my app, or do I add all the source to my project and try to compile it along with the rest of my app?
I'm interpretting this question as:
"Should I compile the C library code once, and include the binary library in my project? Or should I include all the source and compile it every time I build my app?"
It depends. One of the projects I work one depends on several external libraries. Basically, we have a simple rule:
Do you think you will need to change code in the C library often?
If you will be changing the code, or updating versions often, include the source and build it with the rest of your project.
If you're not going to change the code often or at all, it might make sense to just include the pre-built binary in your project.
Depending on the size of the library, you may want to set it up as a distinct target in your project, or for even more flexibility, as a sub-project of your main project.
If I was in your place, I would build libssh2 ahead of time and just include the binary library in my iPhone project. I would still keep the libssh2 source around, of course, in case it does need to be re-built down the road.
I have an iPhone app that is 90% c. I have had no problem adding 3rd party sources to my project and compiling. I am using Lua, zLib, and libpng with no modifications. I've also included standard libraries like unistd and libgen and they just workâ˘
The Three20 iPhone library has a great howto on adding their library to your xcode project. Give that a shot.
I think you will find in the long run you will be better off building it into a standalone library and linking it with your application. This makes it easier to integrate into future apps. Another benefit is that it encourages code separation. If you feel pretty confident with the library, you can link your debug exe to the release build of the library and get some extra performance.
I can't really think of any downsides to creating a library, after the initial cost of setting it up, and having an extra project to modify if you have some changes that need to be made to all your projects. Even if you don't know how to make a library for the iPhone, this is a good excuse to learn.
Just adding the source to you project should work fine as well.
Right now, I'm particularly interested in reading the data from MP3 files (ID3 tags?), but the more it can do (eg EXIF from images?) the better without compromising the ID3 tag reading abilities.
I'm interested in making a script that goes through my media (right now, my music files) and makes sure the file name and directory path correspond to the file's metadata and then create a log of mismatched files so I can check to see which is accurate and make the proper changes. I'm thinking Ruby or Python (see a related question specifically for Python) would be best for this, but I'm open to using any language really (and would actually probably prefer an application language like C, C++, Java, C# in case this project goes off).
There is a great post on using PowerShell and TagLibSharp on Joel "Jaykul" Bennet's site. You could use TagLibSharp to read the metatdata with any .NET based language, but PowerShell is quite appropriate for what you are trying to do.
use exiftool (it supports ID3 too). written in perl, but can also be used from the command line. it has a compiled windows and mac version.
it is light-years ahead of any other metadata tool, supporting almost all known audio, video and image files, supports writing (not just reading), and knows about all the custom/extended tags used by software (such as photoshop) and hardware (many camera manufacturers).
#Thomas Owens PowerShell is now part of the Common Engineering Criteria (as of Microsoft's 2009 Product Line) and starting with Serve 2008 is included as a feature. It stands as much of a chance to be installed as Python or Ruby. You also mentioned that you were willing to go to C#, which could use TagLibSharp. Or you could use IronPython...
#Thomas Owens TagLibSharp is a nice library to use. I always lean to PowerShell first, one to promote the language, and two because it is spreading fast in the Microsoft domain. I have nothing against using other languages, I just lean towards what I know and like. :) Good luck with your project.
Further to Anon's answer - exiftool is very powerful and supports a huge range of file types, not just images, but video, audio and numerous document formats.
A Ruby interface for exiftool is available in the form of the mini_exiftool gem
see http://miniexiftool.rubyforge.org/