I need to embed a tiny webserver in a compiled jsfl external library for Adobe Flash CS4 so that an outside process can communicate with it. The external library will be a Carbon bundle on Mac and a set of dlls on Windows, so the webserver will need to be embedded/loaded from C/C++ code with no external dependencies like Ruby. Most of the tiny webservers like fnord or mini-httpd have never been ported to the Mac or Windows but are mostly intended to be compiled on Linux. I was thinking of using a Lua based embedded webserver but not sure if that would work or not. Are there any embedded webservers that are easier than others to port to Windows and Mac?
All right, I finally answered this. After evaluating several webservers I found a gem, Mongoose. Mongoose is a very small embeddable web server written in C that compiles and runs easily on Linux, Mac, and Windows (there is an even a link in the wiki to getting it to run on the iPhone). Many webservers say they do this but Mongoose was really easy to get up and running. It just did exactly what I expected a little web server to do with minimal fuss. My previous approach, to use libevent or libev, I found a bit too hard, mostly because of threading issues I faced with my main GUI thread. Mongoose came with support for CGI and PHP but I actually found the C based handlers very easy to write so I stuck with that.
Webrick and Mongrel run on both.
I thought of one other idea that is easier than Lua that I will try: using a webserver built with libevent. All I really need to do is serve up one file and I don't need any other HTTP features so something like the following might work:
http://3.rdrail.net/blog/libevent-webserver-in-40-lines-of-c/
I will report back.
Related
Given that ZeroBrane is all written in Lua, can it be actually started from within a Lua environment?
The main motivation would be to fully integrate it inside an existing application (running within the same thread), being able to debug locally using all the exposed C/C++ functionality.
I realize I would have to match the architecture of the clibs used by ZeroBrane with the one used in the host application. So for example, if the host app is running LuaJIT 64-bit I would then require wx.dll compiled against the same LuaJIT binaries.
Will there be any other hurdles or limitations when trying to do this?
Given that ZeroBrane is all written in Lua, can it be actually started from within a Lua environment?
The answer to this question is definitely "yes", as this is what ZeroBrane actually does. For example, on Windows it launches itself by loading src/main.lua and executing it; this code can be seen in win32_starter.c.
Will there be any other hurdles or limitations when trying to do this?
I think the issue you're likely to run into is that it's difficult to debug a single-threaded application from itself (not impossible though). This is why normally the IDE (and its debugger) is launched as a separate process that interacts with the application that's being debugged over socket. You may want to check debugger.lua, which may be closer to what you're looking for.
I am currently testing the GTK Application that I built on windows using the MSYS2 64bit shell.
For the program to be able to run outside of the shell, I packed all the required DLLs with it as well as the following:
FOLDER\lib\gdk-pixbuf-2.0\2.10.0\loaders\\*
FOLDER\lib\gdk-pixbuf-2.0\2.10.0\loaders.cache
FOLDER\share\glib-2.0\schemas\gschemas.compiled
FOLDER\share\icons\Adwaita\\*
FOLDER\share\icons\hicolor\\*
The good news is: It works :) And it also works flawlessly on another PC that doesnt have GTK/Msys2/whatever installed.
The bad news is: On yet another PC (I have tested it on 2 other Systems other than my developing System so far, one one of them it works flawlessly), the program itself works, but the GUI is not rendered sharply (texts are blurry).
Do you guys have any idea on what could be the reason for that? I'm guessing it could be one of the following:
The affected system could have some general display problems that have nothing to do with my app.
The gschemas.compiled file does not suit the affected system. In that case I would probably have to create that file dynamically, but I have no idea how to do this.
I am missing some file from GTK or Glib that would solve the problem.
I am thankful for any help :) Compiling/Deploying a GTK App for Windows has proven to be a pain in the ***, but since (almost) everything works now, I feel like its not much that I am missing unless I have overseen something critical.
Regards,
tagelicht
Given the way you created your package, my bet is that you are missing some components, making the drawing code use some fallback routines, hence the "sharp" drawing.
Try to run the application in command line on the machine where your have the problem, to see if there are some unusual warnings you don't have when running it on your machine.
See also my answer on how to distribute a GTK+ application on Windows.
I need your advices what to use - Layered Service Provider or just load mine DLL in all
process and hook necessary functions using, NCodeHook or EasyHook library.
This is needed for inspection of HTTP traffic.
P.S. This need to be done for commercial application
Thanks!
Before making a decision you need to consider the following:
Code hooking:
AV doesn't like code hooking, if you're using a library that has external DLLs, run a check with AV total before committing to it.
Make sure the library's license works for you, for example, for LGPL you won't be able to embed the library as static without becoming GPL yourself.
I heard people managed to hook Metro apps, it's something to investigate.
If you have another code hooking app, it may conflict.
LSP:
The default MS sample/installer is broken.
You may get something working on a VM or fresh install, but to get LSP working properly across all OS and browsers, will take 6-12 months.
Will not work with Metro apps.
In Komodia we use a combo of LSP/WFP for our SDK, knowing what I know now, if I'd go back 4 years, I'd use LSP all over again.
Good luck.
Using Easyhook will be a nice way to do it check the following http://www.sghaida.com/easyhook-for-systemcall-hooking/
How do you port a Cocoa/Mac application to Windows? I mean how would you go about it? Assume the app was written with Objective-C and Cocoa, there's nothing fancy going on, no "engine" that could be factored out, etc.
Rewrite from scratch? I don't think there will be huge overlaps between the Mac and Windows codebases, right?
I have doubts about cocotron.
Its not clear from the cocotron website that cocotron is actually production ready yet. Id suspect that it would be possible to start new app development and use cocotron constantly to maintain and test windows builds on the go.
But to retrofit it into an existing project might be a much larger task. There are also no alternatives to cocotron - other than perhaps gnustep.
The practical approach to cross platform development involves developing the non gui components of your application, once, in C or C++. And then using a cross platform GUI library like QT - which is VERY good at generating and using native UI where possible or faking it where not. Please DO go to qt.nokia.com and download the latest build of QTCreator for windows and mac - See how the same QT application looks and feels very convincingly native on both platforms.
If QT doesn't provide a native enough solution, then you need to develop your GUI twice :- once in Cocoa, and once in Win32. The cocoa GUI would be in objective C of course, the Win32 GUI in C/C++.
Your non gui application code would - written in c++ - not be able to call Objective-C directly, but its not hard to write shim classes, implemented in .mm files - the provide a c++ interface, and wrap access to an objective c object or class.
You are also going to have to come up with an alternative to CoreData on windows - perhaps sqlite? Given that XCode has integrated support for the sqlite framework, and testing multiple code paths is, well, more work - perhaps dropping CoreData in favor of a common layer is a better approach?
The problem with Objective C is its very poor support on any platform that is not OS X. You can attempt to use the Cocotron, but I wouldn't consider it production ready yet.
For portability, a re-write is in order. With judicious use of standard C or C++ for the "core" of the application, you could still implement platform specific GUI code. If you don't like maintaining two GUIs, you can also try a toolkit such as Qt
Depending on which objects and framework you are using for your cocoa app, you might be able to get away with using gnustep, although the end result will probably look very weird to windows users, and the development environment might be a bit difficult to setup at first.
Are you aware of Cocotron? It looks like the project may have gone stale, but it's a good starting point anyway. It's a project to port Core APIs.
If your application is not cleanly separated (ie: a la MVC) then the only solution is a rewrite, I think.
I'd like to be able to send a Ruby app to some colleagues without requiring them to install a Ruby interpreter. A single exe would be preferable.
I googled and found "RubyScript2Exe".
What are your experiences with that? Are there other such tools or are there better approaches altogether than building an exe?
I've used it about 3 times and I haven't had any problems with it and I ran one of the apps on 10 servers and never had any issues. So, I think RubyScript2Exe is about as good as it gets for ruby.
_why's Shoes framework lets you package the program as an executable for Mac or Windows that installs Shoes (contains a Ruby interpreter). Information about using the packager is here. _why also gives hints about how he makes the Windows executable here.
Don't forget OCRA [1] which I used a couple of times and which Just Worked.
I used to create my exes with RubyScript2Exe as mentioned above but had problems when used with Ruby 1.9 [2].
[1] http://ocra.rubyforge.org/
[2] http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/343891
There is another one called Crate. You can find some information about it here. However I haven't tested it on Windows.
Sorry to be late to the party, but I found this question in my search for trying to do this myself (starting to use SO more and more as a primary resource).
Anyway, I have just had success with exerb, although I'd add a couple of notes:
The web page says exerb runs on any platform. That is true; however if you "compile" a program calls out to native code, then exerb will embed your system's native code (e.g. Linux .so files) into the .exe. In practice, that means you have to build any significant app on Windows.
The web page also says ruby -r exerb/mkrbc but the actual command is ruby -r exerb/mkexy.