HOW POWERFUL IS LAZARUS FOR WEB AND MOBILE? lazarus / 38-Networking and Web Programming ---------------------------------------------------------------------- jufau · 2015-11-25 11:54 Hey guys, I am wondering how good Lazarus is in the web and mobile fields. I know that delphi has Intraweb, which seems to be pretty close to the most pupular ones (PHP and Java) and also compile its application for iOS, Android, MacOS, etc. I've been working on a Windows Desktop Application in Lazarus and I can consider myself very happy with the results. So should I expect the same results if I choose Lazarus to build my web and mobile apps? I just don't want to waste my time learning something that is not going give me what I need. ---------------------------------------------------------------------- Leledumbo · 2015-11-25 12:10 For web, so far so good. fcl-web shall provides most web needs, combined with fcl-json, you can create JSON based webservices consumer in minutes. For server needs, fpWeb is good enough, Brook framework is decent, Habari Web Components are great, too. mORMot... just try it yourself, it's simply complete. For mobile, it still struggles to be user friendly. I don't think it will be soon, but surely the path goes that way. ---------------------------------------------------------------------- jufau · 2015-11-25 13:09 Hi Leledumbo Thank you for your information. It really seems to worth learning fpweb. I am going to start learning some tutorials about it. thanks again ---------------------------------------------------------------------- chrnobel · 2015-11-25 19:56 Quote from: Leledumbo on November 25, 2015, 01:10:06 pmFor web, so far so good. fcl-web shall provides most web needs, combined with fcl- json, you can create JSON based webservices consumer in minutes. For server needs, fpWeb is good enough, Brook framework is decent, Habari Web Components are great, too. mORMot... just try it yourself, it's simply complete. I am using Powtils, and am very fond of it - the webservers I make are really fast and reliable. And it seems like Lars have restarted further development: http://z505.com/powtils/news.shtml ---------------------------------------------------------------------- fpcoder · 2015-12-05 02:59 @SymbolicFrank The question is perfectly fine, this is not StackOverflow. And please don't be rude to people. ---------------------------------------------------------------------- Deepaak · 2015-12-05 08:37 @Kapibara, I Agree with you ---------------------------------------------------------------------- SymbolicFrank · 2015-12-05 10:18 Ok, I'm sorry. ---------------------------------------------------------------------- eny · 2015-12-05 21:01 Quote from: SymbolicFrank on December 05, 2015, 11:18:51 amOk, I'm sorry. For removing your rude comments? I start to understand why your post from SO was removed ---------------------------------------------------------------------- SymbolicFrank · 2015-12-07 09:50 About mobile: As far as I know, FPC is one of the few compilers that can generate native code for both iOS and Android. Delphi, Java and Xamarin C# are the only others I know of. Unity is another option. The main problem with mobiles is the user interface. If you want native GUI elements, you cannot simply recompile your application. A Lazarus LCL application won't run as such on iOS and Android, AFAIK. There are basically two options: use controls that are custom drawn, like FireMonkey for Delphi, or Unity (as it is a 3D game engine), which look like the platform ones, or code the GUI separately for each platform. The only platform that has a set of components comparable to Lazarus which runs on mobiles is Delphi. But I have doubts about the long-term stability of that. And they're not native GUI elements, they just look like them. Lazarus does have a custom drawn interface, but it's pretty basic. Alternatively, FPC 3.0 allows you to use the native GUI of both Android and iOS. A native GUI is possible with FPC, but then you have to separate the business logic from the GUI and write that for each platform. With Java and Xamarin C# you would have to do that as well. There is another point: even if you use a custom drawn GUI that is the same for every platform, they are still different platforms. You still have to take care of platform-specific details in your code. All in all, the only real "write once, compile to multiple platforms" development kit is Unity. But if you don't mind making multiple GUIs, Lazarus is a great choice. Because it has one of the best libraries of components you will want and need when making business apps. ---------------------------------------------------------------------- jack616 · 2015-12-07 11:26 QuoteAs far as I know, FPC is one of the few compilers that can generate native code for both iOS and Android https://en.wikipedia.org/wiki/Native_code See section: Relationship to bytecode You may wish to check other terminology also. ---------------------------------------------------------------------- SymbolicFrank · 2015-12-07 15:16 Yes, I know. I skipped over a lot of other things as well. Edit: You can build the code for the iOS GUI in Apple's XCode. You can also click and drag the GUI elements and forms there. That seems to work well, if you can get the right versions of all components installed and configured. For Android there is (as an example) Pascal4Android, but that is closed source and partly Chinese. But it seems to work well. Windows Mobile is a moving target, with many one-off versions from Microsoft. I expect that the FPC guys will become interested to target it when it stabilizes. With the new version of Lazarus that uses FPC 3.0, a lot can and probably will improve even more. ---------------------------------------------------------------------- SymbolicFrank · 2015-12-08 09:55 About Android: Android is a special case in a lot of things. Behind the screens, iOS runs on BSD in Linux compatibility mode, just because that has a commercial license. You don't have to publish your changes and you can ask money for them. Android uses Linux as well, so it seems that it is very comparable. But that's not the case. Because Android runs in the Dalvik JVM. It is completely written in Java. For example, if you want to play a video on Android, you need a Java application, that creates a Java Framework Media Player. (https://quandarypeak.com/wp-content/uploads/android-media-player- architecture.png) If you would want to use real native code (ARM instructions), you would have to supply an IPC and JNI interface, and still need a Java application on top. So, for all intents and purposes, Java bytecode is the native code on the Android platform. And, FPC 3.0 has that as a compilation target.  But there is more. While you would think, that writing native applications on Android gives you more control, Google has created their own platform: Google Play Services. That is what you need to interface to use the specific Android services. And you do that through Java as well. To recap, as a stack: Your application Android Framework Dalvik JVM JNI Google Play Services IPC Framework Linux And if you want to create IPC extensions, you can do that with FPC as well. It's a different target platform, but that doesn't matter. ---------------------------------------------------------------------- jack616 · 2015-12-08 10:31 QuoteSo, for all intents and purposes, Java bytecode is the native code on the Android platform. I refer you to the post I made previously. If you are going to discuss a technical subject make the effort to understand the terminology you are using first. You apparent inability to do so is the reason I still dont have a clue what it is you are trying to say. ---------------------------------------------------------------------- SymbolicFrank · 2015-12-08 14:52 Android itself is a Java application. The machine on which it runs is a JVM. The JVM 'processor' runs Java bytecode. ---------------------------------------------------------------------- marcov · 2015-12-08 14:53 Quote from: SymbolicFrank on December 08, 2015, 10:55:27 amAbout Android: Android is a special case in a lot of things. Behind the screens, iOS runs on BSD in Linux compatibility mode, just because that has a commercial license. Afaik iOS, like OS X is mostly FreeBSD userland layered over an own kernel, and there is no "linux compatibility" mode enabled. ---------------------------------------------------------------------- SymbolicFrank · 2015-12-08 16:36 Yes. I wrote a multi-platform threading library some time ago, that runs on Windows, Linux, OS X, iOS and Android, and while Apple does try to rewrite everything to their own standards, the whole POSIX model is intact and everything is surprisingly "Linux compliant" on that level. Or perhaps it's the other way around, as I did find many things that originated with Apple. After all, they exist for 40 years, and they did write many of those low-level libraries that everyone uses. If you browse far enough through the #includes, You'll still find all that code written 40-50 years ago buried underneath. ---------------------------------------------------------------------- marcov · 2015-12-08 17:01 Quote from: SymbolicFrank on December 08, 2015, 05:36:06 pmOr perhaps it's the other way around, as I did find many things that originated with Apple. After all, they exist for 40 years, and they did write many of those low-level libraries that everyone uses. As said it comes from FreeBSD.  POSIX is a whole different kind of beast. It is a set of requirements a Unix like OS must adhere to. ---------------------------------------------------------------------- jack616 · 2015-12-08 23:51 QuoteThe machine on which it runs is a JVM. The JVM 'processor' runs Java bytecode. Once again I refer you to the answer  I gave previously. The term "processor" relates to the hardware. The jvm is a software abstraction that runs bytecode. The 'processor' runs machine code - which it may or may not convert itself into microcode. bytecode or pCode is an intermediate step toward this. ---------------------------------------------------------------------- SymbolicFrank · 2015-12-09 13:56 @marcov: An OS kernel is basically something that does task scheduling and memory management. It has an interface to attach drivers and stuff, and an API for programs. If I build one for a microcontroller, it is at most a few kilobytes in size. There is an interesting anecdote between Tanenbaum and Torvalds about that. BSD, Linux and Apple all write their own ones. They are written in C, which requires a C compiler and runtime. Those C runtimes and the libraries that go with them are for the most part the same, and written long ago. POSIX was a successful project to standardize the API of different OSes, and it is one of the highest level interfaces in the C runtimes and libraries (libc). Richard Stallman had a lot to do with that. And that's what they all used to build that kernel and the rest of their OS. On that level, there is even little difference between Windows and Linux. Although their APIs are quite different. But as programmer, you tend to use the libc API in the first place, with all the platform SDK headers that go with it. And they are very much alike. They all use the same code underneath. @jack616: The binary code (machine code) that runs on many current processors, like all x86/AMD64 CPUs, is actually pCode as well. Those processors are actually VMs with a different CPU underneath. They have a tiny JIT compiler on board, that translates the x86/AMD64 CISC instructions into truly native RISC ones. Even more so: they mostly have multiple, different processors tucked away on their die, all with their own instruction set. And with quite a complex scheduler and memory manager on top, to manage all the different instruction threads and all the available (on-die) memory, like the register files and the cache memory. ---------------------------------------------------------------------- SymbolicFrank · 2015-12-10 22:45 Ok. *takes a deep breath* Now that is all out of the way. And I do apologize for the aggressive mail I posted before (and deleted). I just had a really bad day. My mistake. It seems I'm human after all  Anyway, let's discuss "web". What is web? Anything that uses JavaScript, CSS and HTML? Or that runs in a browser? Or that uses the http(s) protocol? Perhaps to tunnel random stuff through firewalls and proxies? Any socket that provides SOAP/XML/JSON/REST/RAW? Or are we discussing the server side? On what level? The http(s) server itself, CGI/PHP-alike page creating code, middle-ware, MVC/MVVM/WPF models or complete content generating frameworks? Or perhaps the client-side (JavaScript) frameworks that do things like showing and zooming pictures, or client/server AJAX frameworks like JQuery? Then again, nowadays we have "Cloud" as well. That tends to be the server side. Or perhaps only for non-web related things? Ssh/putty? NFS? Where do we draw the line? Where would an X-Server go? Or is that among what people call "Remote Desktop" (RDP)? It generally takes me some time when talking to people to understand what they mean by terms like "mobile", "web" and "cloud". But when I find out, I can help them with it. I do have to admit: I mostly (seriously) prefer automatic software distribution over webapps. Simply because webapps are very complex and very limited, and tend to be extremely chaotic. Mostly because almost nobody builds their own client and server, and knows what is actually send over the wire. Well, I do, of course. It's not hard. But it makes the discussions hard, as you're coming from a vastly different abstraction level. ---------------------------------------------------------------------- jack616 · 2015-12-11 12:12 My best guess is you have learned your terminology online from other people who were themselves just a little confused on some topics. Not suprising given the many attempts by various people to re-name various things. Microsofts absurd notion (to both justify and hide criminal behaviour) that windows is an OS being the funniest perhaps. You are repeatedly applying incorrect terminology and attempting to justify the missuse. I applaud your obvious attempts to research online but suggest a bit more care with your sources. Now you wish to discuss "the web" What I suggest is that you use a blog or those "social media" things for that. This is a forum - forums are not well suited to long abstract conversations. This thread also has a different topic. If you have specific questions or information about the suitability of lazarus for web (or mobile) use that would be appropriate in this thread. But do try to use technical terminology a bit better - or just accept it when corrected. ---------------------------------------------------------------------- JanRoza · 2015-12-11 21:32 Is there still any Lazarus connection in this discussion? As far as I'm concerned this discussion has no place on this forum. ---------------------------------------------------------------------- marcov · 2015-12-11 21:56 Quote from: SymbolicFrank on December 09, 2015, 02:56:47 pmBSD, Linux and Apple all write their own ones. Are you sure that BSD<>Apple here? With respect to libc I mean. QuoteThey are written in C, which requires a C compiler and runtime. Those C runtimes and the libraries that go with them are for the most part the same, and written long ago. Two of the three targets you name use LLVM, which is not that old. And as you said, C runtimes are paired with compilers.... QuotePOSIX was a successful project to standardize the API of different OSes, and it is one of the highest level interfaces in the C runtimes and libraries (libc). Richard Stallman had a lot to do with that. Mostly different Unices, with some extremist claiming it was universal (as long as the other OS was unix like or emulated it) QuoteAnd that's what they all used to build that kernel and the rest of their OS. On that level, there is even little difference between Windows and Linux. Yes. There is a very big difference. The Windows kernel is not POSIX, and only C apps use the C runtime, as on Windows there is a difference between the C language runtime (ms*crt) and the general application user library (user32.dll) QuoteAlthough their APIs are quite different. But as programmer, you tend to use the libc API in the first place, with all the platform SDK headers that go with it. And they are very much alike. They all use the same code underneath. This is not true for Windows at all. The Platform SDK headers are not on top of the C runtime. The C runtime uses the Platform SDK headers. ---------------------------------------------------------------------- SymbolicFrank · 2015-12-12 01:19 @jack616: You might want to research this a bit. @JanRoza: It certainly is! We'll get back to it. ---------------------------------------------------------------------- SymbolicFrank · 2015-12-12 02:51 Quote from: marcov on December 11, 2015, 10:56:40 pmQuote from: SymbolicFrank on December 09, 2015, 02:56:47 pmBSD, Linux and Apple all write their own ones. Are you sure that BSD<>Apple here? With respect to libc I mean. It's not libc as such, it is the source code behind it. QuoteQuoteThey are written in C, which requires a C compiler and runtime. Those C runtimes and the libraries that go with them are for the most part the same, and written long ago. Two of the three targets you name use LLVM, which is not that old. And as you said, C runtimes are paired with compilers.... Yes, they use LLVM. The thing is: would you switch to LLVM if it couldn't compile your gcc project? Or with a minimum of fuss? Those code bases are HUGE. QuoteQuotePOSIX was a successful project to standardize the API of different OSes, and it is one of the highest level interfaces in the C runtimes and libraries (libc). Richard Stallman had a lot to do with that. Mostly different Unices, with some extremist claiming it was universal (as long as the other OS was unix like or emulated it) QuoteAnd that's what they all used to build that kernel and the rest of their OS. On that level, there is even little difference between Windows and Linux. Yes. There is a very big difference. The Windows kernel is not POSIX, and only C apps use the C runtime, as on Windows there is a difference between the C language runtime (ms*crt) and the general application user library (user32.dll) Windows is just as POSIX-compliant as the *NIXes, just in a slightly different manner. The threading model and the Inter-Process Communication are the main differences. But even those are based on partly the same source code on the lowest level. QuoteQuoteAlthough their APIs are quite different. But as programmer, you tend to use the libc API in the first place, with all the platform SDK headers that go with it. And they are very much alike. They all use the same code underneath. This is not true for Windows at all. The Platform SDK headers are not on top of the C runtime. The C runtime uses the Platform SDK headers. It's both. Let's start at the bottom. Without a kernel, there is no memory management. So, no malloc. No variables, unless they're registers. And some CPU's have only a single, or a few usable registers. So, the first thing you have to do is make the memory manager. But, how are you going to do that? Is your kernel going to hand out memory allocation for each variable? Or only for larger blocks? The thing that interests the kernel is the prevention of conflicts. And perhaps the coherence, but that's a different discussion. Like a subroutine might have to push the registers it wants to use on the stack, and pop them back before returning, it's up to the kernel to make sure all the memory a process can access is available when it is running. Or to have an interrupt in place to do that JIT, on the moment the process tries to access it. Most current kernels that I know of use paging to do that, and almost all of those use 4kB pages. For the most part because the CPU can do that as well. So, the moment a process tries to access some part of memory, the kernel is going to make sure the right memory page is "loaded" at that location. And that's all most kernels do for memory management. (Well, there's drivers and other resources, but that's not relevant here.) To your application (the process), it looks like you have kilobytes (for 16-bit applications), megabytes, gigabytes or even an almost limitless amount of memory (for 64-bit applications). But how you are going to make sure your variables, buffers and instances all have their own space is up to you. And the same goes for the kernel, as it also needs space for those things. So, they both have their own, fine-grained memory manager as well. Which is probably the same one, if both are written in C. Or if you use cmem in Lazarus. Or a different one if you don't. So, there are two (actually more, but not for now) different memory management schemes, of which the fine-grained one is probably the same for the kernel as well as many applications. Another great example are sockets. Almost everyone still uses the same socket code, as written nearly 50 years ago by people from Berkley University, while the internet was still called ARPANET. And all those things are part of the runtime and/or default library. The kernel needs to make sure that your average C application compiles, which requires that both of those are supported. And it needs that runtime itself as well to function. Only Intel builds their own compiler and runtime, everyone else uses gcc. Even a new design like LLVM needs to have a functional compiler before it is able to build itself. And it should be compatible with it. The same goes for FPC. Next up the ladder has historically been C++, or Objective-C for Apple. Same thing, different implementation. The main difference is the event (messaging) model. You need a functional C compiler, with the "default" libraries and runtime to bootstrap it. Which expands the libraries and runtime available. And you use THAT language to build the rest of your OS (driver and software management, userland, at least one (G)UI and the all- important API).    When building a high-level application, you can stick to the high- level API for your interface. But that API is part of the OS, which uses all those lower-level interfaces itself. Which are included in the headers of the platform SDK. And the only reason you might not be able to use those as well is that they might run in (protected) kernel mode. But even so, it all uses the same code underneath (for the most part). If you want to make your code platform independent, you can either stick to the common demeanor, or you can research the header files and libraries to see where the different platforms diverge. And what the actual code underneath does. On that level, even the threading model of Windows and *NIX is alike. Then again, it was more different in the past. Or at least, it looked like it. Critical sections versus semaphores. But nowadays everyone uses the same, simplified mutexes for everything. Although spinlocks are still used by the kernel in some rare cases. So, behind the screens, on the lowest level, Windows actually uses something that is very much alike the simplified pthread model that the *NIXes use as well. And while Apple has become a bit less compliant with the changes originating by their move to make everything reference counted, and as they use a much simplified event model for their GUI (they skip the formal events and use messages for everything), that's only an issue if you use the top level API. Which you have to do if you want to use their GUI. FPC is one of the few non-Apple development platforms which can do that. Delphi, for example, circumvents it. TL;DR: almost everything is build on top of the same, huge library of code that was written about 40 years ago. Most of the differences are in the top levels, the actual runtimes and libraries are mostly the same.