Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / lazarus / 2013-05

windows rt

6 messages · 5 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Unknown author

Hello,

Does anyone know if it possible to use pascal code in windows rt as for the windows market now or really zero chance? I know that there is no fpc port but maybe with some hacks would work...

My code does not use anything from the platform, not even file access, it is only logic. I was wondering if I could make it into a dll and call the dll from a .net program. I wonder if this would be acceptable for microsoft. Probably not from their rules... win32 is banned and the rtl uses it. Maybe they will be merciful since I am not using those rtl routines? Anyone tryed?

Also, does anyone know if the executable format at least in win rt is the same? pe format and available in both executable and dll forms?

thanks,

Felipe Monteiro de Carvalho

Reply by email

Sven Barth
to Unknown author
Show quoted text 5 lines
Hello, Does anyone know if it possible to use pascal code in windows rt as for the windows market now or really zero chance? I know that there is no fpc port but maybe with some hacks would work... My code does not use anything from the platform, not even file access, it is only logic. I was wondering if I could make it into a dll and call the dll from a .net program. I wonder if this would be acceptable for microsoft. Probably not from their rules... win32 is banned and the rtl uses it. Maybe they will be merciful since I am not using those rtl routines? Anyone tryed?

If you're really adventurous you could try to compile the unit for Win32 or Win64 (depending on the platform) and link the resulting .o file to your code (I don't know whether you can use the MS linker for that or whether you must use the GNU binutils). Your code must not call the RTL in any way however (this includes strings, dynamic arrays and classes; objects would be ok if you allocate the memory using functions from the Windows API which are available for WinRT) and you must check whether API functions you use are really available for WinRT (if you import API functions you might also need to link the libimp*.a file).

In summary: it would be quite restricted, so a port would be a better solution...

Also, does anyone know if the executable format at least in win rt is the same? pe format and available in both executable and dll forms?

It's the same.

Regards,
Sven

Reply by email

Felipe Monteiro de Carvalho
to Sven Barth
Sven Barth wrote
must use the GNU binutils). Your code must not call the RTL in any way however (this includes strings, dynamic arrays and classes; objects would be

Umm, that's too nasty. I surely need strings, arrays and classes, or else one must write some kind of useless spaguetti code. So I guess it is a no way for Windows Store for now.

ok if you allocate the memory using functions from the Windows API which are available for WinRT) From what I read what is available for allocating memory in WinRT is

malloc from the Visual C RTL.

> Also, does anyone know if the executable format at least in win rt is the > same? pe format and available in both executable and dll forms? It's the same.

This part is really good! So one could theorically use the win32 binutils and just copy the existing RTL and delete all calls to the WinAPI and substitute it to Visual C RTL calls to make a quick and dirty port ...

Anyway, the amount of work needed to support it looks larger than the platform is worth for me ... so I'll just go back to porting my app to Android and forget Windows Store for now.

I was mostly interrested in the $100 bucks that MS is willing to pay per application developed:
http://www.zdnet.com/microsoft-offers-developers-cash-to-write-windows-8-apps-7000012851/

But now I noticed it is only for people that live in the United States =( So there is no hurry to support a platform with currently nearly zero market share.

Felipe Monteiro de Carvalho

Reply by email

Sven Barth
to Felipe Monteiro de Carvalho
Felipe Monteiro de Carvalho wrote 5 lines
> ok if you allocate the memory using functions from the Windows API which are > available for WinRT) >From what I read what is available for allocating memory in WinRT is malloc from the Visual C RTL.

Yes, nevertheless the RTL needs to be adjusted for this, because the heap manager uses the HeapAlloc function from kernel32.dll and not the Visual C RTL.

Show quoted text 8 lines
>> Also, does anyone know if the executable format at least in win rt is the >> same? pe format and available in both executable and dll forms? > It's the same. This part is really good! So one could theorically use the win32 binutils and just copy the existing RTL and delete all calls to the WinAPI and substitute it to Visual C RTL calls to make a quick and dirty port ...

The big work of a WinRT port of FPC is exactly this substitution of API calls. Adding a new target to the compiler and the build utilities is easy. Implementing the RTL is the hard one and you'll have to do that no matter whether you do a "quick and dirty" port or a real one. In both cases you'll need to research the correct function to use and the correct way to pass in or retrieve data.

Regards,
Sven

Reply by email

Michael Van Canneyt
to Sven Barth
Sven Barth wrote 11 lines
On 12.05.2013 14:19, Felipe Monteiro de Carvalho wrote: >> ok if you allocate the memory using functions from the Windows API which >> are >> available for WinRT) > >> From what I read what is available for allocating memory in WinRT is > malloc from the Visual C RTL. Yes, nevertheless the RTL needs to be adjusted for this, because the heap manager uses the HeapAlloc function from kernel32.dll and not the Visual C RTL.

if you use cmem, it should ?

Show quoted text 16 lines
>>> Also, does anyone know if the executable format at least in win rt is the >>> same? pe format and available in both executable and dll forms? >> It's the same. > > This part is really good! So one could theorically use the win32 > binutils and just copy the existing RTL and delete all calls to the > WinAPI and substitute it to Visual C RTL calls to make a quick and > dirty port ... The big work of a WinRT port of FPC is exactly this substitution of API calls. Adding a new target to the compiler and the build utilities is easy. Implementing the RTL is the hard one and you'll have to do that no matter whether you do a "quick and dirty" port or a real one. In both cases you'll need to research the correct function to use and the correct way to pass in or retrieve data.

This is the reason Delphi does not support windows RT at the moment. They are too deeply rooted in the Win32 API, and they too must 'rewrite' the RTL.

It will be interesting to see who will be there first :-)

Michael.

Reply by email

Vincent Snijders
to Michael Van Canneyt

2013/5/12 Michael Van Canneyt

Show quoted text 31 lines
On Sun, 12 May 2013, Sven Barth wrote: On 12.05.2013 14:19, Felipe Monteiro de Carvalho wrote: > >> ok if you allocate the memory using functions from the Windows API which >>> are >>> available for WinRT) >>> >> >> From what I read what is available for allocating memory in WinRT is >>> >> malloc from the Visual C RTL. >> > > Yes, nevertheless the RTL needs to be adjusted for this, because the heap > manager uses the HeapAlloc function from kernel32.dll and not the Visual C > RTL. > if you use cmem, it should ? This is the reason Delphi does not support windows RT at the moment. They are too deeply rooted in the Win32 API, and they too must 'rewrite' the RTL. It will be interesting to see who will be there first :-)

Sounds like the situation on *nix where some targets use the syscall api (like current win32 and win64) and some the libc api (like win RT).

Vincent
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20130513/bea7229f/attachment-0001.html>

Reply by email