Hello, I would like to ask whether is it possible to write program as usual then compile it but result wouldn't be a standard binary but a .jar file usable on mobile devices which can run java programs. Because for me as a FPC/delphi coder it would be great if I could code program and output could be .jar file which I could run on my mobile. Thanx in advance for Any advice
Pianoman

Hello, I would like to ask whether is it possible to write program as usual then compile it but result wouldn't be a standard binary but a .jar file usable on mobile devices which can run java programs.

No.

Because for me as a FPC/delphi coder it would be great if I could code

Java byte code is too limited to use it in an object pascal implementation as you know it from FPC/Delphi.

program and output could be .jar file which I could run on my mobile.

Get a linux or windows ce based one :)

> usual then compile it but result wouldn't be a standard binary but a > .jar file usable on mobile devices which can run java programs. No.

You can find some more reasoning in the .NET/JVM faq item :

http://www.freepascal.org/faq.html#dotnet

Hello!,

Native code is what you need on these (usually) memory constrained devices to get the full bang for the buck. If you check the wiki, you can find that the symbian os port is a work-in-progress.

If java bytecodes are an absolute necessity then maybe you can check Midlet Pascal (mentioned in the lazarus forum).

btw, is it true j2me is being scrapped in favour of the "full" j2se?

Cheers,
-Krishna

BTW, can anybody point us to emulators of these devices (I know Embedded Visual C++ has an ARM WinCE emulator)?

Leonardo.

__________________________________________________ Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

Leonardo M. Ramé wrote

BTW, can anybody point us to emulators of these devices (I know Embedded Visual C++ has an ARM WinCE emulator)?

Recently I installed Nokia Carbide.c++ and the Symbian SDK for my N72 phone. One of these packages comes with a virtual phone (donno which one though). But these are huge downloads wonder what is inside.

<rant> the C++ "Hello,World!" code that the wizard spit made me think Symbian OS is a pig. I sincerely hope that there is a better way to program these devices. </rant>

Cheers,
-Krishna

Krishna wrote

<rant> the C++ "Hello,World!" code that the wizard spit made me think Symbian OS is a pig. I sincerely hope that there is a better way to program these devices. </rant>

I am working on the Free Pascal port, but because of the horrible way the symbian SDK was created, their extremely slow support and the fact that their API is fully C++, its going slowly.

Yeah, I saw the wiki page. Does it work on S60 2nd/3rd edition phones too?

How do you map the C++ API? by hand? Is it possible to tailor the "Direct class wrapper"
(http://milan.marusinec.sk/articles-icu4pas/icu4pas-dcw.html) approach to ARM?

Cheers,
-Krishna

Krishna wrote

Yeah, I saw the wiki page. Does it work on S60 2nd/3rd edition phones too?

No. But they are similar, so if uiq works, the s60 support can be build reusing a lot of what was developed for uiq. The base operating system is the same, so I guess the RTL would need few or no changes, but this is just a guess.

The GUI toolkit is completely different so that would need new bindings.

The mksymbian build tool will need to be adapted to the specifics of the s60 sdk

How do you map the C++ API? by hand? Is it possible to tailor the "Direct class wrapper" (http://milan.marusinec.sk/articles-icu4pas/icu4pas-dcw.html) approach to ARM?

They seam to rely on assembler there, so I guess no.

And yes, I am currently mapping it by hand.

Actually they seam to also be relying on the calling convention and on specific compiler information, which wouldnt work for symbian because they use several different compilers and also they dont guarantee binary compatibility between different sdk and os versions.

In the SDK that I installed with Carbide I remember seeing binutils and friends. So I suppose that a GCC cross compiler is being used for building the code which means g++ is a supported compiler. Now, assuming that the symbian os itself is built using another compiler and the fact that g++ is binary compatible with the abi means that a bridge to g++ should be compatible with the binaries of other compilers. No?

Don't compilers conform to the standard c++ abi for the ARM? (http://www.arm.com/pdfs/cppabi.pdf)

Another thing, the code produced for the winemulator target is x86 code or arm code?

Cheers,
-Krishna
p.s: I'm completely new to this so pardon my ignorance.

Krishna wrote

Another thing, the code produced for the winemulator target is x86 code or arm code?

Depends. The Visual Studio 2003 emulator is x86. Based on the VirtualPC core product. The Visual Studio 2005.. um.. I don't remember. I know Microsoft provide an ARM emulator that runs dog slow. I had the emulator and WM6 images about 5 months ago in my last job. Testing against the x86 emulator is only good for quick tests. Nothing beats debugging on a real device. If you pony up the cash, you can do that with VS2003 or VS2005.

Let me just point out.. and this isn't a troll, it's my own experience: The end user does not care what your application is written in. Just so long as it works. As such, I would recommend Compact Framework and managed code for any Windows Mobile device. The memory footprint is minimal - all WM5 devices I have used (and we used quite a few brands) have the Compact Framework in ROM. Speed wise, it's fast. It doesn't the significant bugs Microsoft had in their native code SQL Server CE 2.0 - as an example of native code on mobile devices, C# and CF.NET make life far, far, far simpler. I found it cut development time down by between 50% and 70%. I can't even look at old code written using C anymore. Shudder.

As for the FPC compiler targeting CLR.. It could be done. But why would you need to? Use Chrome instead. Why reinvent the wheel. I see no advantage in porting Legacy Pascal code to a new disparate platform. Especially when said platform does things a lot more pleasurably.

M

We are talking about Symbian OS here. For linux and windows mobile devices, I understand you can use FPC directly, right?

As for the FPC compiler targeting CLR.. It could be done. But why would you need to? Use Chrome instead. Why reinvent the wheel. I see no advantage in porting Legacy Pascal code to a new disparate platform. Especially when said platform does things a lot more pleasurably.

Legacy Pascal? Din't generics get added in the last release? Anyways, I'm not asking for a CLR/JVM port. FPC already generates code for the target (here, ARM) it is only the OS interface that we are talking about.

Cheers,
-Krishna

Sorry, you said Winemulator. I read "windows emulator" not "emulator for windows". My bad.

All native Object Pascal is legacy code for me. I haven't used Pascal in a new project for .. um.. 3 + years. Last job I maintained a Delphi app, but all new dev was in DotNet. I don't see going back to Delphi as an option, ever. I keep on this list because I have ~15 years of Object Pascal legacy code under my belt and I still really like Pascal. I want to use it, but it's just not possible at the moment. Things might change soon, I'm entering the world of MacOS X soon. Though MONO is on the MacOS X platform, so I might not even then.

Does FPC support the flavour of Linux on the N800? That might also be something I'd like to look at.

M

Yes, but the emulator has different versions for many compilers, so using this would mean giving up using the emulator.

Another thing, the code produced for the winemulator target is x86 code or arm code?

x86

Its actually a simulator

En/na Matt Emson ha escrit:

Does FPC support the flavour of Linux on the N800? That might also be something I'd like to look at.

No :-(
All packages for the n800 are armel, i.e. they use EABI, while fpc generates OABI calls.
I don't really know all the details of OABI vs EABI, I only know that a simple "hello world" compiled with FPC, since it's a static application, worked on the n800. Anything more complex doesn't. For the record, I also tried to compile a C application natively on another arm processor, with standard debian (i.e. OABI), the n800 didn't even recognize the binary. Once I statically linked it, it ran with no apparent problems. Again, it was a simple console application, nothing fancy.

Bye

(My last job switched to C#, and has recently switched back to native delphi for normal apps, so back to delphi except for ASP.NET)

soon, I'm entering the world of MacOS X soon. Though MONO is on the MacOS X platform, so I might not even then.

Lazarus looks mighty fine natively on Mac. What does Mono have to counter that?

Marco van de Voort wrote

Lazarus looks mighty fine natively on Mac.

It may one day, but currently it is still very far from that. For example, pretty much every setting wubdiw has a wrong button layout. On the Mac, if you have a single "ok" button, it should be on the bottom right (in Lazarus they are in the middle). If you have an "ok" and "cancel" button, the "ok" should be on the right of the "cancel" button (in Lazarus, they are ordered the other way around). Also, all those icons in the menus look pretty weird (very few Mac apps have that, and none that I currently use does), and the icons in the toolbar look out of place compared to icons other Mac apps (mainly because of the limited colour palette and lack of anti-aliasing in the drawings, I guess).

In general, for now it still looks and feels very much like a pure Windows or Linux application with an Aqua skin. That may be fine for Windows/Linux users coming to the Mac, but it would make me click on the wrong buttons all the time.

I have great respect for Tombo and the others who have done a great job porting the LCL to Carbon, but it takes a whole lot more work than that to look and feel "mighty fine natively on Mac". The same will probably go for any Lazarus/Delphi app ported to the Mac, for that matter (unless Lazarus can do automatic button layouting, and if the current layout mismatch is simply due to some wrong default setting for the Carbon target).

Jonas

Jonas Maebe wrote

go for any Lazarus/Delphi app ported to the Mac, for that matter (unless Lazarus can do automatic button layouting, and if the current layout mismatch is simply due to some wrong default setting for the Carbon target).

Actually, we have a TButtonPanel exactly for this purpose. It's just that (A) not all dialogs use it yet (B) it doesn't get the right default setting from Carbon yet.

Perhaps not very easy fix, but the infrastructure exists.

Micha

See Micha's comment. Maybe I also should have added "for a first version" btw.

True, but it is a big step ahead:
It is much better than installing X11 and gtk1.

As Micha said: A TButtonPanel has been started. Michael VC, Paul and me fixed some bugs this week in FCL and LCL so it can now be used for the IDE dialogs. see below.

Also, all those icons in the menus look pretty weird (very few Mac apps have that, and none that I currently use does),

Should they be hidden?

and the icons in the toolbar look out of place compared to icons other Mac apps (mainly because of the limited colour palette and lack of anti-aliasing in the drawings, I guess).

Ok. AFAIK this is already reported.

In general, for now it still looks and feels very much like a pure Windows or Linux application with an Aqua skin.

Apple had always a very good and very distinct design, so I guess we will always have to make some compromises.

Then we have to find out, how other cross platform visual libs are handling it. The TButtonPanel is one solution, but it only works with ok,cancel,close,help buttons. Maybe we should add an easy way to automatically switch Ok and Cancel buttons.

Mattias

While I do not dispute the validity of your comments, I'd like to point out that any cross-platform solution will suffer from this. Be it in Mono, Java or FPC. I'm sure the Eclipse or Mono generated programs have the same problem.

The main point is that the Mac port of Lazarus currently enables you to create cross-platform applications. Additionally it also enables you to create applications that will look OK on the Mac as well, if you were to code them natively on Mac, using the Mac standards.

And as for 'looking mightlily fine', I can assure you that the Mac port was really the unique selling position of Lazarus/FPC on Systems, last week. The Windows Vista-64-bit and Mac Aqua IDE running on 2 screens next to each other were real eye-catchers.

So some optimism and cheerfulness is definitely in order, I'd say :-)

Michael.

Op Sat, 27 Oct 2007, schreef Michael Van Canneyt:

Lazarus is by far the "most native" cross platform solution in existance. Certainly, it cannot compete with hand-tuned non-portable GUI code, and it probably never will. But writing hand-tuned non-portable GUI code requires a lot of resources, and therefore only feasible on big platforms. Lazarus allows you to create cross-platform applications with not perfect, but still remarkable native look and feel.

I have one complaint in this regards: Lazarus applications respond, like native applications to "theme" changes in the OS (as native applications should). However, try to change the colour scheme on Win32, the Lazarus IDE looks terrible, because some GUI parts obey the colour scheme and others don't.

Daniël

Sounds great. Can we add this sentence to the main page? :)

AddBugReport();

Mattias

Op Sat, 27 Oct 2007, schreef Mattias Gaertner:

Sounds great. Can we add this sentence to the main page? :)

Certainly.

AddBugReport();

Done.

Daniël

Mattias Gaertner wrote

> Also, all those icons in the menus look pretty weird (very few Mac > apps have that, and none that I currently use does), Should they be hidden?

In general, I would say: yes. Maybe it should be an option which by default is off, or so.

Jonas

Op Mon, 29 Oct 2007, schreef Jonas Maebe:

I think it doesn't apply just for Mac, the latest Lazarus snapshots have menu bars that are overcrowded with icons. This is unusual for any platform I use.

Daniël

I don't know about that?
I use quite some programs and they all have icons in front of many many menus. Kile, konqueror, k3b etc. Not much less than Lazarus.

Normally, under Windows the convention is that you put an icon in front of any menu item that corresponds with a toolbar button (with the same icon). It makes clear that the menu item/button have the same function. Menu items for which no toolbar button exists, do not have an icon.

Michael.

Maybe this discussion can be moved to the lazarus list.

Mattias

>> Also, all those icons in the menus look pretty weird (very few Mac >> apps have that, and none that I currently use does),

Also, on Windows I found the spacing was a bit big but not sure if this is normal MS OFfice style look and feel since I don't use that software much.

For example it looks like a tab between the icon and the menu item, rather than say two spaces.