This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [Fwd: Bug: Perl:IsWinNT undefined & RFE, only use "/" in reg values, not names..?]


What features does one get with a unix perl over a perl built where "WinNT" is
defined as true or false? Many (most? all?) of the Win32 calls are available
in the Cygwin environment, why not compile the perl as a mixed breed perl that
defines WinNT?


What is lost by allowing Perl to make libwin32 calls.

If Cygwin is supposed to enable me to run my utils and scripts from bash or
cnd.exe, then why should perl be different? What do I lose by defining -MWin32
in the PERL5OPS?, or put another way, why isn't it on and present all the time?


Besides, it seems, that the cpan modules for perl can't be for active state
perl since they have their own package manager -- but are for the floundering
win32-perl that is mostly eclipsed by active state's perl and cygwin's perl.


I suppose I find it frustrating to find books/examples about win32-perl that
don't quite work on active state and don't quite work on cyg_WIN_ (vs. a
cygunix product that might infer a variant of unix).

It seems cyg_win_ was designed to add POSIX  and unix compatibility and
functionality to the _Win_ environment with the intent of making things
_easier_ (Easy is good -- not everyone can be a master of every technology).
So why not make things easier for perl scripters as well by starting with
a perl that is unix (works with cpan, handles paths with "//", "/") and
win (paths handle "\\", ":" and "\\\\" and define WinNT) compatible?

Is there some fundamental reason why they can't both be present in perl?

I think part of the problem is that Perl is both an "app" (can be view as
a unix app to be transferred over), or can be viewed as part of the
development environment (as it is a development tool) that also understands
it is running in a mixed mode.

I'm favoring the latter view, obviously, while some have taken the former
view.  I'm just thinking it makes cygperl so much more accessible/useful to
have it understand it's mixed mode heritage as well.

Is that something real difficult or impossible to do?

(I don't know, never having built perl in the first place.)

Linda



Brian.Kelly@Empireblue.com wrote:

Seems to me you answered your own question. The perl that's bundled with

Cygwin is *NOT*
an Active-State-*like* Win32 version of perl. It's really a *unix* built
version of perl that
-requires- Cygwin to even run on Windoze at all. That being the case,
Cygwin perl *thinks* its
running on unix - not Win32. Therefore, modules that expect direct,
non-POSIX access to the
Win32 subsystem are gonna need some help that wouldn't otherwise be
necessary with a true
Win32 build of Perl.

Brian Kelly




--
   In the marketplace of "Real goods", capitalism is limited by safety
   regulations, consumer protection laws, and product liability.  In
   the computer industry, what protects the consumer?



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]