Unix assumptions in perl (Windows/CE port) 
Author Message
 Unix assumptions in perl (Windows/CE port)

I'm going to start a port of Perl 5.6.0 to Windows/CE.

I've just started to look at the Perl source, and would like to locate
the areas where I'll find problems. Most of these problems look like
they're due to Unix assumptions in Perl.

I have read perlport carefully. And I've looked at the Win32-specific
code, as well as the efforts made to port python to the CE devices.

It looks like the Unicode support put in for Win32 platforms will be a
good start. There are no API's in Windows/CE that take anything other
than Unicode characters in their arguments, so either I'll have to
provide an ANSI-to-Unicode mapping in cases where (say) filename
arguments are given as non-Unicode strings, or I need to disable the
non-Unicode strings somehow in these contexts (is this even possible?).

Some of the extraneous Windows garbage that I can get rid of includes
the idea of "drive letters".

Other Unix assumptions that I've noticed in Perl source code (including
modules) that I'll have to work around include:

1. fileno() returns small integers

2. select() takes bitfields which can be constructed from the output of
fileno()

3. there is a "current directory" that one can change

4. there exist filenames relative to the "current directory"

5. fork() exists.

6. files have owners, users have ID's, etc.

7. there exist a number of other system calls that are exposed with the
same name in Perl but don't exist on this platform (same situation as
in Win32).

8. alarm(), signals exist

Now, I can deal with (1) and (2) by keeping an array of OS handles
around and using their indices as file handles.

(3) and (4) can be dealt with by keeping a pseudo-current directory
internally

(5) can probably be ignored for now.

(6) and (7) can be ignored. (8) is annoying but maybe ignorable.

There is limited stdio support on the HPC/Pro but not on other members
of the WinCE family (pocket-sized, HPC). I may have to write a library
for this.

Can anyone think of any other assumptions in the Perl source that might
bite me? Or (for those of you who are familiar with WinCE) what should I
look out for? This is my first WinCE programming project, though I've
done Win32 and Unix programming in the past.

For those of you who are not familiar with the HPC/Pro version of WinCE,
note that it has more memory and storage available (at least on my
machine, with CF cards) than the first Unix box I worked on (256K RAM,
80Mb HD). And the processor is probably faster, as well (131 Mhz MIPS
4121 vs. DEC LSI-11/23).

Why am I doing this?

 * Because I have a couple of HPC/Pro devices that I would like to use
   Perl on.

 * Because Python and Scheme have already been ported to the platform.

 * Because I like Perl.

Note (though this should go without saying) that comments about
Microsoft and its evil empire are irrelevant and will be ignored by me
(though I am not a big fan of theirs).  I use Linux as my primary
operating system, and do my WinCE development on NT under VmWare. And I
know about the Linux effort on these devices, and don't think that I
would like to use it right yet.

-- Ned Konz
currently: Stanwood, WA

homepage:   http://www.*-*-*.com/ , Perl: http://www.*-*-*.com/



Thu, 31 Oct 2002 03:00:00 GMT  
 Unix assumptions in perl (Windows/CE port)

Quote:

>    Ned> 1. fileno() returns small integers
>    Ned> 2. select() takes bitfields which can be constructed from the
>    Ned> output of fileno()
>    Ned> 3. there is a "current directory" that one can change
>    Ned> 4. there exist filenames relative to the "current directory"
>    Ned> 5. fork() exists.
>    Ned> 6. files have owners, users have ID's, etc.
>    Ned> 7. there exist a number of other system calls that are
>    Ned> exposed with the same name in Perl but don't exist on this
>    Ned> platform (same situation as in Win32).
>    Ned> 8. alarm(), signals exist

>None of these assumptions is true when Perl is built for a Win32
>environment, so most of the hard work should be done, shouldn't it?

Certainly a lot of it is done. Some of the above assumptions are
in fact true for NT but not for CE, though:

NT has a concept of a current directory, while WinCE doesn't.

fork() exists in 5.6.0 for Win32.

WinNT (at least with NTFS) has file ownership. It also has user ID's. I
don't know how Perl exposes these (have to look more at the win32 port).

NT has a set of API's that take ANSI strings and an equivalent set that
take Unicode strings. The existing Win32 port chooses between these.
WinCE only has the Unicode set.

There does seem to have been work done for Win32 that unifies the concept
of sockets and file handles. (USE_SOCKETS_AS_HANDLES).

--
Ned Konz
currently: Stanwood, WA

homepage:  http://bike-nomad.com, Perl homepage: http://bike-nomad.com/perl



Thu, 31 Oct 2002 03:00:00 GMT  
 
 [ 2 post ] 

 Relevant Pages 

1. Corrupted paradox indexes HELP!

2. perl port to windows CE ?

3. perl for Windows CE 2.0?

4. ANNOUNCE: Perl for Windows CE

5. PERL in Windows CE?

6. Perl/Tk on Windows CE?

7. Q: Restructure a table and change TableName of a TTable during run time

8. Delphi with Ingres

9. Help ! Porting from unix to windows, unicode problem

10. Porting from Win32 perl to Unix perl

11. Help via porting From Win32 Perl to Unix Perl

12. quick reports vs. ReportSmith

 

 
Powered by phpBB® Forum Software