ExeOutput 2 is finally going to be released before the end of this year.
The first public Beta will be available on October 2015 if everything works as expected.
In following weeks, we will try to publish some compiled PHP applications made with the first Beta, so that everyone can test them. In next post, you can see some screenshots of our WordPress demo.
ExeOutput 2 is different from previous 1.x releases and we hope it will bring more possibilities.
We rewrote the entire PHP part of ExeOutput: in version 1.x, we used a built-in PHP SAPI module so we were tied to the PHP 5.3.x branch and some PHP features were not correctly handled.
In version 2, we now use PHP CGI directly as an external process. This brings several advantages:
PHP is separated from the UI process, giving more stability and responsiveness.
If the PHP process crashes, a new one is started if you refresh the webpage. Your application itself doesn’t crash.
We can now support more recent PHP versions! Support for PHP 5.4 and 5.6 is already implemented in ExeOutput 2. We aim to allow you to select which PHP version you want to work with, directly in ExeOutput interface.
We still want to support Windows XP so we have to keep PHP 5.4, the last version that officially runs on this OS.
Our new implementation should be OK with the incoming PHP 7.
More testing is necessary though.
These changes allowed us to compile and run complex PHP applications. For instance, WordPress can now be turned into a desktop application with ExeOutput 2. The application can be easily deployed (no need of MySQL thanks to the third-party SQLite integration plug-in). WordPress could not run with ExeOutput 1.x.
PHP 5.4 and 5.6. PHP 5.5 should be included too (or as an add-on that can be downloaded through the Web Update utility).
Full integration between PHP and Chromium rendering engine. AJAX, cookies, file upload and download dialog boxes, custom request and response HTTP headers, Developer Tools…
ExeOutput 2 can still generate one single EXE file for distribution (unless you decide to keep dependencies as external files). Due to the size of the Chromium and PHP distributions, the EXE overhead’s size is near 30 MB.
We are now focused on the Chromium engine so we dropped the Trident engine support in ExeOutput 2. However, it should be a temporary decision. For Windows 10, Microsoft ended development of Internet Explorer and its associated Trident engine (except security fixes). Currently, they don’t provide a way to implement the same engine as Microsoft Edge in legacy Win32 applications. It is said this could change in the future.
When importing an ExeOutput 1.x project, the engine is automatically set to Chromium.
New interface editor to create customized toolbars, menu bars, ribbons… The downside is that custom toolbar buttons and menus from ExeOutput 1.x projects can’t be imported in ExeOutput 2.
Better support for PHP frameworks.
Console applications based on PHP CLI are also on the roadmap, but we are not sure whether they will be made available in the first Beta.
WordPress demo screenshots (real demo coming soon for download)
ExeOutput 2 can compile the WordPress blog engine into a single EXE file, allowing you to run WordPress-powered websites without the need of a local web server and MySQL server (if you use SQLite as in the demo).
Below you can see screenshots of an application that runs a basic WordPress website. This demo was run on Windows 10. Windows 10 is fully supported!
I really hope this is a temporary decision, else I may as well forget about Exeoutput 2 for the time being…
The trouble is, with Chromium use being so limited in Exeoutput V1, many of your customers hands have been tied and we’ve been forced to develop all but the most basic of apps using Trident platform just so they function properly, and in my case, not only that, but in IE7 compatibility mode too with all its CSS hacks and workarounds. So whilst I understand your desire to focus on Chromium, to drop Trident altogether would leave myself and surely many others with some VERY serious work on our hands, especially when it comes to apps with detailed custom interface design and complex javascript.
At present, when I open my app in IE, or run the compiled exe from the current version of Exeoutput, it looks and functions perfectly, it’s taken a lot of intricate work and hacks to get it to that stage, but when opened in Chrome, not only is the interface a complete mess visually, many parts of it simply refuse to function and throw JS errors all over the place… I do like a challenge, but the prospect of debugging it to function correctly in Chromium is daunting to say the least…
So stay with your old 1.7 if it works for you. If somebody application works under DOS he should stay with DOS, we need EXEOUTPUT 2.0 and if needed it should break compatibility with old 1.7, and true is that it should break compatibility.
Obviously V2 is bound to be a powerful tool, and well worth the wait for many - I’ve been waiting for well over two years too! I’m well aware Chromium is a better platform and a good move for compatibility, and rewriting my project for Chrome would be a good thing to do at some point when time allows.
I just feel it would have been nice for them to have provided us with a more minor update to 1.7 a long time ago with just a few of the more basic features and bug fixes we were promised (on the old forum before it was suddenly removed) rather than have us wait 3 years for a complete re-write with lots of bells and whistles that breaks compatibility with IE altogether.
If Windows 95 had broken compatibility with DOS, then it would have been a complete commercial failure. The reason it was the success it was was down to a lot of effort by Microsoft to minimise BC-breakages as much as possible (e.g. see http://ianmurdock.com/platforms/on-the-importance-of-backward-compatibility/)
I don’t know how many people the lack of Trident support will affect (it doesn’t affect me) but if it is a lot this sounds like a very bad commercial decision, and must be particularly galling for people who have been waiting 2 years for an upgrade only to find out that they can’t use it without a large upgrade expense.
If this group is a small minority, then it’s no big deal, but I suspect the majority of people built using Trident, as Chromium was considered ‘experimental’ in 1.7, so this could end up pissing-off a lot of customers, which is never a great thing for a business to do!
As I wrote, if the application has not been updated for almost three years, everyone who used it had to stop using it or made a lot of solutions, workarounds and restrictions so that it somehow functioned, and the client reconciled to it. There is a rule that better is enemy of the good, so if something works it shouldn’t be touched. Maintain old application with old exeoutput and create new application in exeoutput 2.0.
I do not want a new version was compatible with the old version in any case. I want the new product to measure the present time, I would like to producers are freed from compatibility and accelerated the creation of the current version of which is delayed by almost three years. Please do not compare early period of the consumer market for operating systems: text mode to graphics mode, which is easy to embeded in grapics mode. Exeoutput is an application that allows you to create embeded browser, the server and interpreter in one container. Moreover, Trident will no longer be supported in Windows.
That’s my personal opinion. I do not want to wait another 3 years to ensure compatibility because three years in IT is the next era and the product is again not up to date.
You were the one who made the comparison with DOS. I could have picked any number of more appropriate examples, but I was responding to your specific example.
You’re entitled to your opinion, and the developers are entitled to do what they want with their software. I’m not even saying it will turn out badly! However, the risk is there.
I do not want a new version was compatible with the old version in any case.
Really!? You are happy for backwards-compatibility to be broken with every release? You obviously don’t use (or don’t plan to use) ExeOutput for anything serious. Anyone considering the software for a serious project, with actual customers, would not want to take on that kind of risk to their business, and would look for an alternative more-stable solution, even if it initially costs more.
(Not that I think it will break with every release - I am just responding to your point.)
My preference has always been for chrome (webkit) !
ie (trident) most often have to use hacks or other commands to work well.
What I understand is that there will be a short delay.
I purchased Exeoutput earlier this year and my projects use the chrome engine, so I’m not bothered about the Trident engine missing in the first beta’s. I’m super excited to finally get my hands on the webrtc controls. Am I going to have to re-purchase the upgrade, or will I get it anyway?
I have been wanting to buy ExeOutput for some time now but every time looked at, the last update (think 2013 if I recall) turned me off. Was worried it would become outdated with Windows 10 coming. So glad to hear moving on the version 2!
So now I wonder: if I buy 1.7 now, is the version 2 included in upgrade or will it cost me more when released?
Just an ole school teacher and district does not pay for my tools such as GDSoft:)
After a cup of coffee see the wording of updates. Major and minor with paid plan. Sold me so bought extra year:) Cannot wait to see V2. Sure it will be great as cannot get anything working with current version. Hope it was not a $200 mistake…
I am developing a php application on standalone system using XAMPP (PHP Version 5.5.15) and evaluating it on Google Chrome Browser (Ver. 44) so Is ExeOutput 2 give me same results which I get by XAMPP + Chrome?
most often have to use hacks or other commands to work well.