(avoiding to hitchhike the other thread))

LacaK wrote

Same in our company. We use Motorola mobile computers with WinCE 5 and WinCE6 and we compile native applications for them. (So WinCE support is for us very important) -Laco.

I understand that Microsoft on the long run will try to have the Wince (and WinPhone ?) users to upgrade to the Windows 10 product line.

I understand that with Intel Arch, fpc/Lazarus "Windows" programs will simply run in Win 10 IOT Core (and a colleague of mine already tested that his Delphi programs do run on Win 10 IOT Core on a MinowBoard Max.)

What about Win 10 IOT Core for ARM ? I suppose that some work needs to be done to support Win 10 IOT Core on ARM.

-Michael

WinCE6 and we compile native applications for them.

(and WinPhone ?) users to upgrade to the Windows 10 product line.

That depends on the devices. Some manufacturers might prefer to stay with WinCE, because it's easier to adjust to their hardware (namely because they already have drivers for their hardware).

What about Win 10 IOT Core for ARM ? I suppose that some work needs to be

done to support Win 10 IOT Core on ARM.

It depends on whether normal WinAPI programs will work there. If they do, great, then we simply need a port of our win32 target for ARM. If not... Hard stuff... Then a completely new port for the Universal Windows Platform will he needed... (but then we'd also be able to run on Windows 10 Mobile or the Hololens)

Regards,
Sven
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20151016/5ceb0b39/attachment.html>

I thought not?

Michael.

According to https://ms-iot.github.io/content/en-US/Faqs.htm : -----
Are true console apps supported on Windows 10 IoT Core?

True ?console? apps aren?t really going to be supported for the IoT core OS, headless or not. You can still deploy and run a standard win32 console app here, it just won?t be connected to any on-device console. When running headless you should just get that black screen. When running headed the only supported UI is via the UWP UI stacks (XAML, HTML, DirectX).
-----

Ant there is a tool to check compatibility of ordinary WinCE apps: https://ms-iot.github.io/content/en-US/win10/tools/IoTAPIPortingTool.htm

Best regards,
?ilvinas

So, that is not the GDI winapi...

Michael.

I asked my colleague who tested this with the MinowBoard Max and he confirms that Delphi programs do run as Services (with an Event Queue but without a GUI), but normal applications don't show a form.

-Michael

Michael Van Canneyt wrote

So, that is not the GDI winapi...

I understand that it is meant as a replacement for WinCE (and of course to fight Linux), but not as a competitor for Desktop Windows.

But happily, Delphi (and very likely Windows-fpc-) programs will run.

Seemingly sending "Messages to Windows" works with IOT even if such a window is never visible. So Lazarus applications might run normal but invisibly using the Win32 Application widget type.

Maybe on ARM the WinCE application type might work ???

-Michael

"Michael Schnell" wrote

Maybe on ARM the WinCE application type might work ???

I doubt very much that Microsoft ported the WinCE API to their NT based system and yes, they use very different libraries.

Regards,
Sven
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20151016/1d2e2144/attachment.html>

Michael Van Canneyt wrote

So, that is not the GDI winapi...

Obviously.So a Delphi program never will show a a Form.

But with Lazarus, the "fpGUI" and "Custom Drawn" widget sets should work, as - AFAIK - they can be configured to use DirectX.

-> Graeme can you comment on this ?

-Michael

As far as I know, fpGUI works on GDI.

Michael.

Michael Van Canneyt wrote

As far as I know, fpGUI works on GDI.

I suppose you are right. I did not re-check in Windows, as I don't use Lazarus on windows right now, but maybe erroneously just used my remote memory.

Rephrasing:

On Linux, fpGUI can be configured to use either "GDI" or "X11" as "fpGUI Platform". So it might be doable to have fpGUI use DirectX as a platform.

With that - other than Delphi - Lazarus programs would be able to show their Forms. Yet another argument to use Lazarus rather than Delphi :-) .

-> Graeme can you comment on this ?

Thanks
-Michael

as - AFAIK - they can be configured to use DirectX.

WinAPI vs. UWP is a completely different beast than GDI vs. DirectX whereby the latter is only a very small part of the problem.

To stress this again: We don't support UWP right now as a target in the compiler and RTL.

Regards,
Sven
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20151019/82729292/attachment.html>

I see.

To stress this again: We don't support UWP right now as a target in the compiler and RTL.

Why does UWP need support by the compiler or the RTL ? AFAIK, GDI does not have such either, but only by the LCL.

Thanks,
-Michael (sorry if this ia silly question)

UWP is a complete separate runtime environment on Windows. It is nothing like the Win32 API.
You may not use the Win32 API directly in a UWP application.

That means the headers need to be ported, an RTL needs to be written on top of that. It's still a question to me whether it sports a flat or OOP model (I think the latter). There are some other restrictions as well.

See
https://en.wikipedia.org/wiki/Universal_Windows_Platform and
https://en.wikipedia.org/wiki/Windows_Runtime

All this means you must basically restart from scratch.

Michael.

Michael Van Canneyt wrote

UWP is a complete separate runtime environment on Windows. It is nothing like the Win32 API. You may not use the Win32 API directly in a UWP application.

I did not introduce the term "UWP" here, so I don't know it the non-GUI part of IOT's API is to be called "UWP".

(The message by ?ilvinas was "When running headed the only supported UI is via the UWP UI stacks (XAML, HTML, DirectX", hence only concerning the GUI makeoff ).

But the fact is that Delhi service application (that don't have a GUI) do run normally on IOT, so the part not concerning the GUI seems to be a Win32 API.

-Michael

I *seriously* doubt the first part of this statement, because Delphi explicitly does not support the windows runtime on which IOT is based.

You can find several statements in this regard by Embarcadero employees.

Michael.

Michael Van Canneyt wrote

I *seriously* doubt the first part of this statement, because Delphi explicitly does not support the windows runtime on which IOT is based.

See my message above in this thread (10/16/2015, 03:13):

"I asked my colleague who tested this with the MinowBoard Max and he confirms that Delphi programs do run as Services (with an Event Queue but without a GUI), but normal applications don't show a form."

This person really is not an idiot but a very versatile programmer doing Delphi since it exists, Turbo Pascal before !

You can find several statements in this regard by Embarcadero employees.

Obviously they did not try service applications.

-Michael

I did not claim otherwise :)

> You can find several statements in this regard by Embarcadero employees. Obviously they did not try service applications.

We can at least conclude that there is a lot of confusion about what it is and what it is not;

But seeing that it is Microsoft, this does not come as a surprise... There are more vendors at work than actual programmers in that company.

Michael.

M$ claim that "in future there only will one Windows: Windows 10". I gather that this should mean that there is a common API specification (but obviously "smaller" versions provide just parts of same, but no different specs for the same stuff, any more).

Hence to me it does make perfect sense, that (free) Windows 10 IOT runs service applications normally (via the "basic no-GUI" WinAPI) but does not have the "GDI winapi", and hence is no competitor too the (paid) Desktop Windows 10 versions.

As a result I still think that a "DirectX" version of fpGUI or CustomDrawn that runs on IOT should be doable.

-Michael

Technically speaking, I read once that the user32.dll and advapi32.dll may not be used directly in a Windows Runtime application. Since the service manager calls are in the latter, I assumed that a service application cannot work.

Probably the information I read was inaccurate or it has changed meanwhile.

As a result I still think that a "DirectX" version of fpGUI or CustomDrawn that runs on IOT should be doable.

How do you know that DirectX is part of IOT ?

Michael.

Michael Van Canneyt wrote

How do you know that DirectX is part of IOT ?

Only from the message ?ilvinas posted:

"When running headed the only supported UI is via the UWP UI stacks (XAML, HTML, DirectX"

-Michael

That comes from:
http://ms-iot.github.io/content/en-US/Faqs.htm

I just cheched, and fpgui has no support for DirectX, at least none of the fpgui sources in git supports this.

Michael.

"Michael Schnell" wrote

> > To stress this again: We don't support UWP right now as a target in the

compiler and RTL.

> Why does UWP need support by the compiler or the RTL ? AFAIK, GDI does

not have such either, but only by the LCL.

GDI is merely an API provided in context of the WinAPI, UWP is much more. First of it's an environment which /must/ run on top of the MSVC runtime and secondly not all WinAPIs that our Windows RTL needs and uses are available. In addition there's also the point of the COM classes (many higher level APIs like window handling and drawing are only available through that) for which we AFAIK yet need support in our type library tool. And then UWP apps are packages like e.g. applications on Mac OS X or apps on Android, so the corresponding tools for these need to be used as well...

Regards,
Sven
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20151019/4620cdbd/attachment.html>

Yep. But of course that does not mean that DirectX in fact is supported on a certain hardware platform.

I just cheched, and fpgui has no support for DirectX, at least none of the fpgui sources in git supports this.

I did not assume this. But maybe it can be done with not too much effort.

-Michael

I see.

Thanks,
-Michael

And then you're up shit creek without a paddle.

Hah.... "with not too much effort." is never applicable in IT.

Michael.

The other options statwed in
http://ms-iot.github.io/content/en-US/Faqs.htm are XAML and HTML.

This obviously aim at a remote GUI.

Support for a kind of remote GUI is something that had been discussed here several times. (There once was the EXTPASCAL project, which had died a long time ago).

With Win IOT Core this issue might get a new push.

-Michael

Bwah, I don't really think so.

You're better off using Linux or some BSD for embedded stuff. Why tie yourself to a company such as Microsoft ?

Michael.

And AggPas.

Martin

I personally am thinking along the same lines.

In fact I personally am not planning to do a project with Win IOT. (But I need to recommend it for the company I am working for, due to the huge embedded project they are doing in Delphi, and declined porting to Linux due to lack of manpower.)

But as I think that Microsoft will push Win IOT with their marketing power, and Delphi already does support it with Service Applications, I would not like to see Lazarus in a looser position.

-Michael

Michael Schnell wrote

The other options statwed in http://ms-iot.github.io/content/en-US/Faqs.htm are XAML and HTML.

Yet another option is to stream all functions, properties and events of visual objects via TCPI/IP and provide a project that at the user's site displays the forms of the remote application.

This would obviously be doable, but very propriety and of course a lot of work.

Martin once told me about this possibility by the name of "mse-ifi". I don't know if it is available with MSE-IDE.

-Michael

That is simply the wrong way of doing things.
With browsers or webviews what they are today, you can do all display logic in the browser. The server just needs to provide the suitable data.

Michael.

Of course I do agree that it would be a lot nicer to have a remote GUI that supports displaying forms on a browser (and in fact I do have a device (QNAP NAS) that does this in a way that looks and feels very similar to what is standard with a Lazarus Application. I did not find out whether they did their own Java Script Widget implementation or if they licensed a 3rd party product for that.

But I don't see how somebody will start a new project similar to EXTPascal, that needs a lot of Java Script knowledge and supposedly will only be able to support a basic set of the LCL Widgets. Moreover the HTTP protocol is a bad choice for remoting a GUI, as it does not decently support server->Client signaling.

Moreover such devices often need to provide a standard web server at the same time, and sit behind a firewall/Proxy, making a deployment even harder.

-Michael

They use extjs 3.3. We use QNap too.

Remoting a gui is a bad idea, I would not spend time on this approach.

Michael.

Michael Van Canneyt wrote

Remoting a gui is a bad idea, I would not spend time on this approach.

When GUI was invented it had been done with UNIX and X11. X11 ran on an X-Terminal. So there was no other GUI than a remote one :-) .

Local GUIs got popular with Mac, Atari and Windows a lot later.

-Michael

Michael Van Canneyt wrote

They use extjs 3.3.

-> http://dev.sencha.com/deploy/ext-3.3.1/examples/

This indeed looks like a very powerful remote GUI framework.

-Michael

Except that it is not remote.

Michael.

Michael Van Canneyt wrote

Except that it is not remote.

????

With the QNAP it is remote. Or am I hit by a misconception of that wording ?

-Michael

I understand it as follows:

A browser application (any RIA) such as used in QNA is in fact a client/server application. The client just happens to be a browser.

ExtJS is meant to run in the browser. The gui is built from A to Z in the browser. It is there for a 'local' GUI from the point of view of a developer or end user.

To me, a 'remote' gui is built on the server and then sent to the client (browser). In this scenario, the server has at all times a mirror of what the client sees. This is stateful, therefor not scalable, and in general IMHO should be avoided.

Michael.

So the Client application would completely have to be written in Java Script. (To me: Yuck !!!)

This is exactly what I thought.

You can see it even more in detail:

In a modern PC, the Graphic card's processor renders Text and created things like rectangles, this might be considered very basic widgets.

To the PC's main CPU this processor is remote (i.e. attached via a defined API "Bottleneck"). So in fact any GUI can be considered a remote GUI.

With Linux the X-Server is in between. Same is "remote" (here the API even can be TCP/IP) to the application.

Usually a windowing system and widget set is still in between again "remote" to the application via an API.

In this sense, with a Lazarus application, the LCL might be considered "remote" to the user code.

So there are multiple layers of remoting a GUI and for a logical view, it is not a real difference how large the mechanical space between the client and the server at any API is.

So to me it depends on multiple circumstances (hardware, OS, resources, speed requirement, intended use, deployment issues, ....) if or if not "remoting" any of the multiple APIs is or is not a good idea for a given project.

-Michael

Yes. Any attempt to avoid this is futile.

I tried 2 concepts (one of the ExtPascal).
You ALWAYS end up writing javascript for particular cases.

So, better bite the bullet and do the lot in Javascript directly, using the tools available in Javascript. Even the folks at Google came to this conclusion.

What I do endorse is converting Pascal to Javascript directly. Pascal is better suited for large projects: classes, type safety and so on...

Michael.

Michael Van Canneyt wrote

Yes. Any attempt to avoid this is futile. I tried 2 concepts (one of the ExtPascal). You ALWAYS end up writing javascript for particular cases.

I do see the problem that likely come up. That obviously is why EXTPascal has been abandoned. And that (plus the one directional makeoff of the HTP protocol) is why I think a totally propriety attempt to remote the LCL API (called "ifi") *might* be a better idea than trying to force a browser to show a remote GUI.

So, better bite the bullet and do the lot in Javascript directly, using the tools available in Javascript.

Happily I am not planing such a project, myself :-)

Thanks for the interesting discussion !

-Michael

Yes, this is interesting. I'll repeat what I wrote two years ago: http://lists.lazarus.freepascal.org/pipermail/lazarus/2013-November/084629.html

A *long* time ago I was involved a little with Genotechs in Phoenix and they had a (Delphi) program called AstroMark that sounds similar: http://www.eweek.com/c/a/Enterprise-Networking/Do-You-Deploy-Thin-or-Thick-Web-Applications

That is exactly the working principle of MSEifi. The difference is that MSEifi is not implemented by a Javascript environment but by MSEgui components and widgets written in Free Pascal. On client side a MSEifi runtime which could be implemented as browser plug-in fetches the *.mfm form data (the MSEgui equivalent of Lazarus *.lfm files) and PascalScript snippets and instantiates the forms and datamodules. If wanted there are ifi components available in order to connect data points and events between server and client by a TCP/IP or other serial connection but that is no requirement. The same connection components can be used for separation of GUI and business logic in a standalone desktop application so it is possible to use the same GUI definition in both. At least in theory. ;-)

Martin

Thanks for supporting the general idea.

-Michael

I seem to remember that a fpc java script backend had been discussed. Do we know the state of this project ?

Another theoretical variant would be using Silverlight/Moonlight and _Delphi_for_.Net_ / Prism. I don't know if anybody tried this combination, yet.

-Michael

Martin Schreiber wrote

At least in theory. ;-)

What is the state of the "ifi" project right now ? (AFAIK, you did not publish it for others to use yet.)

IMHO it would be a great building block for fpc users that want to use WIN IOT (or a tiny Linux board, or for other reasons are facing a headless target).

Are there any example that could demonstrate that it's not pure theory :-)

-Michael

"Michael Schnell" wrote

> I seem to remember that a fpc java script backend had been discussed. Do

we know the state of this project ?

Not much progress. Maybe this will change with the new binary format and environment Microsoft, Mozilla & Co. are working on.

Another theoretical variant would be using Silverlight/Moonlight and

_Delphi_for_.Net_ / Prism. I don't know if anybody tried this combination, yet.

You are aware that the trend is to get away from such binary extensions? (see Flash)

Regards,
Sven
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20151020/e0d1c827/attachment.html>

And that's where the ship sinks for me...
Browser plugins are not acceptable as a viable solution.

Michael.

Silverlight is discontinued.

Michael.

In process MSEifi is used in production and standard in MSEide since years, the experimental MSEifi-remote components can be integrated by compiling MSEide with -dmse_with_ifirem. MSEide git master version has them integrated by default.
https://gitlab.com/mseide-msegui/mseide-msegui

Are there any example that could demonstrate that it's not pure theory :-)

There is still the pipe demo I made for you, feel free to build some more. :-)

Martin

Certainly not for universal internet use. In an industrial environment the requirements are different.

Martin

Martin Schreiber wrote

There is still the pipe demo I made for you, feel free to build some more. :-)

Now I remember playing with that some years ago ;-) . As in our company the project had been canceled, I was busy with other things and stopped thinking about that some tome later.

Now it seems to attract renewed interest :-) .

-Michael

Absolutely agreed, but in that use case I tend to think that a desktop application is a problem, and the browser can be bypassed altogether. It is a limited environment after all.

Michael.

Michael Van Canneyt wrote

And that's where the ship sinks for me... Browser plugins are not acceptable as a viable solution.

For me even a stand alone program (compilable for Linux Windows and Mac, at best for Android and iOS, too) independent of any browser would be great.

-Michael

Michael Van Canneyt wrote

Absolutely agreed, but in that use case I tend to think that a desktop application is a problem,

For me, (if any) the main mission is providing a tool kit for porting existing Delphi programs (here to headless embedded targets). Hence the "application" is a predefined constant.

-Michael

Sven Barth wrote

You are aware that the trend is to get away from such binary extensions? (see Flash)

Yep. To me it seems like ".NET" is rather dead altogether (even though M$ does not admit that).

-Michael

Martin Schreiber wrote

There is still the pipe demo I made for you, feel free to build some more. :-)

Maybe you could provide a compiled version (simply two applications) so that the others can see what is possible with that paradigm.

-Michael

There *are* compiled versions I made especially for you and which blow up the repository now. ;-)

https://gitlab.com/mseuniverse/mseuniverse/tree/master/attic/msedocumenting/mse/trunk/help/tutorials/mseifi/ifipipedemo/bin

Martin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mseifi.png
Type: image/png
Size: 38433 bytes
Desc: not available
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20151020/c515c560/attachment-0001.png>

Great !
Thanks for digging that out again. Maybe now it can trigger some more interest.

It really is a shame that I am not any more as much in duty with the Delphi migration Kit as I was those days.

-Michael

I heard there were patents involved but I don't know anything about those.

Regards,
Paul
www.ControlPascal.com

(see Flash)

> Yep. To me it seems like ".NET" is rather dead altogether (even though M$

does not admit that).

The latter point I doubt. For UWP C# is a first class citizen (like C++) and only recently MS announced the results of their work on a .Net JIT based on LLVM.

Regards,
Sven
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20151020/14bde884/attachment.html>

Paul Breneman wrote

I heard there were patents involved but I don't know anything about those.

Happily no software patents in Europe yet :-) , still fighting against TTIP...

-Michael

Michael Van Canneyt wrote

Silverlight is discontinued.

To me this is the death of .NET.

Silverlight was the only excuse to call the CIL runtime ".Net Framework". In fact, to me, Silverlight was the only reason to consider ".Net", because deploying a browser-plugin - in the moment it is to be executed - needs to do this in an architecture and OS independent way, and needs for running the stuff in a "managed" environment. Here, CIL does make sense as it runs complex applications that way with close-to-native speed. (If course Java can do the same, but for obvious reasons M$ wanted to fight Java). Of course it's nice to be able to deploy such a plugin unchanged for local use, but in a local environment, native code deployment usually can easily be done. (An for those who think different, Java/Dalvik has taken it all, anyway).

It's really funny to see how the M$ marketing loves the word "Net", calling the (technical named CIL) perfectly normal virtual processor runtime-environment ".NET" and renaming plain old embedded computing "Internet Of Things", even though (or right because) Linux always technically was preferable in networking, while Windows for a long time was the better choice for desktop computing

-Michael

In fact, to me, Silverlight was the only reason to consider ".Net", because deploying a browser-plugin - in the moment it is to be executed - needs to do this in an architecture and OS independent way, and needs for running the stuff in a "managed" environment. Here, CIL does make sense as it runs complex applications that way with close-to-native speed. (If course Java can do the same, but for obvious reasons M$ wanted to fight Java). Of course it's nice to be able to deploy such a plugin unchanged for local use, but in a local environment, native code deployment usually can easily be done. (An for those who think different, Java/Dalvik has taken it all, anyway).

You are aware that even during its existance Silverlight was only a small part of the .Net ecosystem? There are GUI desktop applications, server applications including ASP.net, Windows Store apps, XBox games. Saying that the discontinuation of Silverlight is the end of .Net appears very far fetched to me. That's a bit as if the end of Symbian would have been used to proclaim the end of Java...

Regards,
Sven
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20151022/8efd7efc/attachment-0001.html>

Sven Barth wrote

You are aware that even during its existance Silverlight was only a small part of the .Net ecosystem?

Of course I am.

"Death of .NET" was a really bad wording of mine. I meant "Death of the .NET (CIL) Framework.

There are GUI desktop applications, ...

Yep I know. I am using several of them myself. and always am unhappy about their extreme slow starting. :(

IMHO Using CIL/.NET for local applications is not a good

small part of the .Net ecosystem?

> Of course I am. "Death of .NET" was a really bad wording of mine. I meant "Death of the

.NET (CIL) Framework.

Doesn't change anything of my argumentation... Silverlight was only a small part of the Framework as well and most other parts are still used by others.

Regards,
Sven
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20151022/75061aa9/attachment.html>

Hello Michael,

Michael Schnell wrote

On Linux, fpGUI can be configured to use either "GDI" or "X11" as "fpGUI Platform". So it might be doable to have fpGUI use DirectX as a platform.

Under Linux, then "GDI" makes no sense - but then I didn't follow this whole thread. The latest development version (and latest released version - with configurable option) relies more on AggPas for all graphic rendering and font support, and the underlying windowing system (Win32, Xlib etc) is used only for top-level windows and some OS events. The reliance on the underlying windowing system is greatly reduced.

I hope this info helps a bit.