Re: [fpc-pascal] Windows on ARM, how fast it can be implemented?
Am 27.03.2013 01:22, schrieb Noah Silva: Well windows has only about 1.5% of the tablet market, and its doubtful if that will grow - plus, as mentioned, it's closed by design. Then again, Apple's app store is restricted, and fpc supports that. This is not about Windows apps. Support for WinRT (aka Metro) would be a completely different topic. This is about running normal desktop applications compied for arm-win32 on a Windows RT tablet and those won't be found in the Windows app store, because you need to jailbreak the Windows RT device to be able to run unsigned desktop applications. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Windows on ARM, how fast it can be implemented?
On 03/27/2013 09:20 AM, Sven Barth wrote: you need to jailbreak the Windows RT device to be able to run unsigned desktop applications. Never buy such a system ! I am not even sure if this is legal in Europe I.e. you are the owner of the hardware. -Michael ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Windows on ARM, how fast it can be implemented?
In our previous episode, Sven Barth said: > > Well windows has only about 1.5% of the tablet market, and its > > doubtful if that will grow - plus, as mentioned, it's closed by > > design. Then again, Apple's app store is restricted, and fpc supports > > that. > > > This is not about Windows apps. Support for WinRT (aka Metro) would be a > completely different topic. This is about running normal desktop > applications compied for arm-win32 on a Windows RT tablet and those > won't be found in the Windows app store, because you need to jailbreak > the Windows RT device to be able to run unsigned desktop applications. Does Metro btw make a difference between the visual, language and system libraries? (like GDI/MSVCRT/win32 in Win32/64) ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Windows on ARM, how fast it can be implemented?
Am 27.03.2013 09:41, schrieb Marco van de Voort: In our previous episode, Sven Barth said: Well windows has only about 1.5% of the tablet market, and its doubtful if that will grow - plus, as mentioned, it's closed by design. Then again, Apple's app store is restricted, and fpc supports that. This is not about Windows apps. Support for WinRT (aka Metro) would be a completely different topic. This is about running normal desktop applications compied for arm-win32 on a Windows RT tablet and those won't be found in the Windows app store, because you need to jailbreak the Windows RT device to be able to run unsigned desktop applications. Does Metro btw make a difference between the visual, language and system libraries? (like GDI/MSVCRT/win32 in Win32/64) I've not looked at this in detail, but AFAIK you only have certain libraries and functions available and it will be checked by the Windows store and the OS that you don't load anything else that you shouldn't load... (you don't even have full access to the filesystem :( ). That's why a complete new OS port would be necessary to support WinRT... Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Windows on ARM, how fast it can be implemented?
On 03/27/2013 10:00 AM, Sven Barth wrote: That's why a complete new OS port would be necessary to support WinRT... A new OS would be more appropriate :-P . -Michael ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Windows on ARM, how fast it can be implemented?
In our previous episode, Sven Barth said: > > Does Metro btw make a difference between the visual, language and system > > libraries? (like GDI/MSVCRT/win32 in Win32/64) > I've not looked at this in detail, but AFAIK you only have certain > libraries and functions available and it will be checked by the Windows > store and the OS that you don't load anything else that you shouldn't > load... (you don't even have full access to the filesystem :( ). That's > why a complete new OS port would be necessary to support WinRT... That's what I heard too, and in addition that most functionality is exposed as (COM) interfaces. But I haven't seen more detail. I hoped for an article in the C'T about it, but either I missed it, or there hasn't been. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Windows on ARM, how fast it can be implemented?
Am 27.03.2013 10:06, schrieb Michael Schnell: On 03/27/2013 10:00 AM, Sven Barth wrote: That's why a complete new OS port would be necessary to support WinRT... A new OS would be more appropriate :-P . I'm not a fan of Windows 8 either, but if I see the possiblity to run FPC apps there, I'll take it. (Seeing that this is also something that Delphi can't do :P ) Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Windows on ARM, how fast it can be implemented?
Am 27.03.2013 10:07, schrieb Marco van de Voort: In our previous episode, Sven Barth said: Does Metro btw make a difference between the visual, language and system libraries? (like GDI/MSVCRT/win32 in Win32/64) I've not looked at this in detail, but AFAIK you only have certain libraries and functions available and it will be checked by the Windows store and the OS that you don't load anything else that you shouldn't load... (you don't even have full access to the filesystem :( ). That's why a complete new OS port would be necessary to support WinRT... That's what I heard too, and in addition that most functionality is exposed as (COM) interfaces. But I haven't seen more detail. I hoped for an article in the C'T about it, but either I missed it, or there hasn't been. Some of the low level API functions are available (but only selected ones) and then there are the COM APIs. Seeing that our support for COM has matured in 2.6 a WinRT port should be doable, but one would need (a) time and (b) a Windows 8 system. I don't have either (the latter mostly, because my university has not yet managed to provide free versions... -.-). Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Windows on ARM, how fast it can be implemented?
On 03/27/2013 10:09 AM, Sven Barth wrote: I'm not a fan of Windows 8 either, ... Is Win 8 on normal PCs crippled in a similar manner or is only the ARM version affected ? -Michael ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Windows on ARM, how fast it can be implemented?
Am 27.03.2013 10:15, schrieb Michael Schnell: On 03/27/2013 10:09 AM, Sven Barth wrote: I'm not a fan of Windows 8 either, ... Is Win 8 on normal PCs crippled in a similar manner or is only the ARM version affected ? Only the ARM version. Though I'd not want to use the PC version either :P Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Windows on ARM, how fast it can be implemented?
On 03/27/2013 10:16 AM, Sven Barth wrote: Only the ARM version. Though I'd not want to use the PC version either :P I'm planning a (kind of) embedded device that need high performance (quad core, 64 Bit, 4 Gig RAM, SSD). I need to use Windows, because of the 3rd party software I need to install. I was told for this Win 8 would offer a better infrastructure than Win 7. In fact I was told that the abysmal Desktop can be deactivated in Win 8. What do you think ? Thanks. -Michael ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Windows on ARM, how fast it can be implemented?
(reply-to set to fpc-other since this is getting off-topic) In our previous episode, Michael Schnell said: > > Only the ARM version. Though I'd not want to use the PC version either :P > > > I'm planning a (kind of) embedded device that need high performance > (quad core, 64 Bit, 4 Gig RAM, SSD). > > I need to use Windows, because of the 3rd party software I need to install. > > I was told for this Win 8 would offer a better infrastructure than Win 7. As windows 6.2, Win8 is a win6 (vista) point release. The main differences are just like Vista->Win7, some minor performance (mainly startup) and startup updates (USB3 in preboot env), some new SMB/NTFS options etc. And performance mainly in the startup. As with any new release, the drivers.cab is updated, so most current common HW is detected out of the box. There are some downsides too, though they mostly are related to the defaults than real issues. (the quick startup is default, but not compatible with many industrial drivers, many shutdown options are hidden by default etc etc ) And of course, the whole startmenu episode is a bit sad, but IMHO a minor footnote just like Vista's gadgets (that have mysteriously disappeared in the next version too). And I hope that electronic delivery will cut out the middle man and thus some of the price in the long run, so the whole shop idea is not that bad, if it isn't forced on you too much. (it is only for MS services like messenger, MS based mail and Skype (I only use skype), and you have to dig out the desktop games from out of the store). Only time will tell. But I never used the startmenu much in the first place, and I consider it an anti RSI measure (if you miss the startmenu in the default location, you probably use the mouse too much :-) Yes, it is still not an improvement overall, but it shouldn't exaggerated. IMHO critics are still a bit power-high over the Vista revolt, and gunning for an encore. The whole discussion only detracts from the real issues and differences. > In fact I was told that the abysmal Desktop can be deactivated in Win 8. Not by standard means. There is a lot of 3rd party cruft out there of course, and even OEMs deliver some, but I wouldn't recommend it. > What do you think ? Win8 vs Win7 is the least important bit of your future device choice. I mildly biassed towards win8, but I mostly migrated because of attractive offers, not features. I would get a 64-bit edition though. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Windows on ARM, how fast it can be implemented?
Thanks a lot for the answers to this very off-topic question. -Michael ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] TStream descendant to compress/decompress gzip data from another stream
Hi,
Like the subject says, I'm looking for a TStream implementation that
takes another TStream and compresses/decompresses data in gzip format. I
would like to read/write gzip data to a stream, any TStream (maybe
TFileStream, maybe TMemoryStream, maybe a stream from the network like
TSocketStream, etc.).
One would think that the ZStream unit will contain something like that,
but it does not. ZStream has:
- TCompressionStream and TDecompressionStream, but they use the "deflate
format", which is different than "gzip format" (gzip format at least
adds some headers around). So you can't use them to directly read/write
data from a xxx.gz file.
- TGZFileStream, which does use the desired "gzip format"... but it can
only read local files (constructor takes just a FileName parameter). It
cannot read from/to another stream.
Is there a stream class that satisfies both these conditions
simultaneously (uses "gzip format" and can read/write to another TStream)?
Offtopic: I probably would avoid the ZStream unit anyway, as it uses
PasZLib, which is a Pascal rewrite of the old zlib code. I would prefer
to rather use ZLib unit (that links to a Zlib library, usually in
so/dll/dylib) instead. Reasons are security (the C zlib library is
probably more maintained than gory internals of paszlib) and because I
have to distribute Zlib library anyway (libpng depends on it, and I use
libpng).
Google found an old thread on lazarus mailing list about this ("FPC,
gzip and stream") but without any solution, everything mentioned there
has either the limitations of TCompressionStream/TDecompressionStream
(no gzip format) or TGZFileStream (not able to work wit ObjectPascal
streams).
Thanks in advance for answers,
Michalis
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] TStream descendant to compress/decompress gzip data from another stream
El 27/03/2013 19:22, Michalis Kamburelis escribió:
Google found an old thread on lazarus mailing list about this ("FPC,
gzip and stream") but without any solution, everything mentioned there
has either the limitations of TCompressionStream/TDecompressionStream
(no gzip format) or TGZFileStream (not able to work wit ObjectPascal
streams).
Hello,
.gz is a quite simple format, but it can not be implemented as a TStream
(only) descendant because in a single .gz file many files could be added
so something like the class to handle .zip files should be used.
Parsing the .gz header is easy, and calling TCompressionStream and
TDecompressionstream over the payload should be easy, but only for the
first file in the .gz
--
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] TStream descendant to compress/decompress gzip data from another stream
José Mejuto wrote:
El 27/03/2013 19:22, Michalis Kamburelis escribió:
Google found an old thread on lazarus mailing list about this ("FPC,
gzip and stream") but without any solution, everything mentioned there
has either the limitations of TCompressionStream/TDecompressionStream
(no gzip format) or TGZFileStream (not able to work wit ObjectPascal
streams).
Hello,
.gz is a quite simple format, but it can not be implemented as a TStream
(only) descendant because in a single .gz file many files could be added
so something like the class to handle .zip files should be used.
The existing TGZFileStream in ZStream unit already shows that it can be
implemented, i.e. TGZFileStream reads gzip data and is a TStream
descendant. I assume that TGZFileStream simply returns the first file
inside a multi-file gzip (otherwise it would need to call gzopen
multiple times, as far as I understand).
This is also my use case: I know that my .gz files should contain only
one file (X3D standard guarantees it for me), I want to ignore the
remaining files (if any).
Parsing the .gz header is easy, and calling TCompressionStream and
TDecompressionstream over the payload should be easy, but only for the
first file in the .gz
I will probably have to implement it then. I was hoping to have
something available ready, since ZStream contains things that are *so*
close (but not quite) to what I want :)
Thanks,
Michalis
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
RE: [fpc-pascal] TStream descendant to compress/decompress gzip data from another stream
I have converted the one from fpc to its own library to do streams , can email
it to you later if you wish
-Original Message-
From: "Michalis Kamburelis"
Sent: 28/03/2013 6:13 AM
To: "FPC-Pascal users discussions"
Subject: Re: [fpc-pascal] TStream descendant to compress/decompress gzip data
from another stream
José Mejuto wrote:
> El 27/03/2013 19:22, Michalis Kamburelis escribió:
>
>> Google found an old thread on lazarus mailing list about this ("FPC,
>> gzip and stream") but without any solution, everything mentioned there
>> has either the limitations of TCompressionStream/TDecompressionStream
>> (no gzip format) or TGZFileStream (not able to work wit ObjectPascal
>> streams).
>>
>
> Hello,
>
> .gz is a quite simple format, but it can not be implemented as a TStream
> (only) descendant because in a single .gz file many files could be added
> so something like the class to handle .zip files should be used.
The existing TGZFileStream in ZStream unit already shows that it can be
implemented, i.e. TGZFileStream reads gzip data and is a TStream
descendant. I assume that TGZFileStream simply returns the first file
inside a multi-file gzip (otherwise it would need to call gzopen
multiple times, as far as I understand).
This is also my use case: I know that my .gz files should contain only
one file (X3D standard guarantees it for me), I want to ignore the
remaining files (if any).
>
> Parsing the .gz header is easy, and calling TCompressionStream and
> TDecompressionstream over the payload should be easy, but only for the
> first file in the .gz
>
I will probably have to implement it then. I was hoping to have
something available ready, since ZStream contains things that are *so*
close (but not quite) to what I want :)
Thanks,
Michalis
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] TStream descendant to compress/decompress gzip data from another stream
Justin Smyth wrote: I have converted the one from fpc to its own library to do streams , can email it to you later if you wish Yes, that would be appreciated. As long as everything you send me is covered by the same license as FPC RTL (LGPL with static linking exception), so that I can use it in my own code and also contribute it back to FPC :) Michalis ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] TStream descendant to compress/decompress gzip datafrom another stream
I will send it later today. i have to find the code and its at work , but i think i have a copy here somewhere... dont need to worry about the license as its just a extraction of one of the units from FPC that needed a few small changes -Original Message- From: Michalis Kamburelis Sent: Thursday, March 28, 2013 9:16 AM To: FPC-Pascal users discussions Subject: Re: [fpc-pascal] TStream descendant to compress/decompress gzip datafrom another stream Justin Smyth wrote: I have converted the one from fpc to its own library to do streams , can email it to you later if you wish Yes, that would be appreciated. As long as everything you send me is covered by the same license as FPC RTL (LGPL with static linking exception), so that I can use it in my own code and also contribute it back to FPC :) Michalis ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] TStream descendant to compress/decompress gzip data from another stream
On 27 Mar 2013, at 19:54, José Mejuto wrote:
> El 27/03/2013 19:22, Michalis Kamburelis escribió:
>
>> Google found an old thread on lazarus mailing list about this ("FPC,
>> gzip and stream") but without any solution, everything mentioned there
>> has either the limitations of TCompressionStream/TDecompressionStream
>> (no gzip format) or TGZFileStream (not able to work wit ObjectPascal
>> streams).
>>
>
> Hello,
>
> .gz is a quite simple format, but it can not be implemented as a TStream
> (only) descendant because in a single .gz file many files could be added so
> something like the class to handle .zip files should be used.
Sorry to just drop in on this quite late, but isn't gzip a compression
algorithm and not a file format as such? gzip (the command line utility) only
compresses one file and *doesn't* put this in a multi-file container. To get
`multi-file gzips`, you will first want to bundle the files and compress this
bundle (files -> tar -> gzip) or compress the files separately and then bundle
them together (files -> multiple separate gzipped files -> tar). Or are we
talking about a different gzip here?
So basically (to answer to the subject of this mail), you will only need a
stream that implements this algorithm, which you could quite easily write
yourself. Take a look at zlibar, it's a project that iirc implements an archive
format that uses gzip. Now there are two functions in there that compress and
respectively decompress a stream and return the result, also as a TStream
descendant. If you cannot find this easily just say it, I've got the code (or
at the very least these two functions) lying around.
If I just said anything anyone has already mentioned, please forgive me, I've
only just read this message and thought to elaborate a bit on it :-)
--
Ewald
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
