| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
| |
HWND_MESSAGE and WC_NO_BEST_FIT_CHARS are not defined by the VC6
headers unless WINVER is set to 0x0500 or higher, but then the
headers will generate a lot of warnings because Windows 2000
was still in beta when those headers where released.
PROCESSOR_ARCHITCTURE_AMD64 is not defined at all in the
VC6 headers.
|
|
|
|
|
|
|
|
| |
The sources did support to drop win32/fcrypt.c from a Perl distribution
and build without a crypt() implementation to account for the paranoia
around distribution of encryption technology. However sources and binaries
have been released for at least 10 years with all the code in place, so
there is not much point in making it configurable.
|
|
|
|
|
|
|
| |
The code works around a bug in very old versions of MSVCRT.dll.
The issue has been fixed a long time ago by Microsoft, so anyone
who has installed a Windows Service Pack in the last 10 years
or so won't be affected by the problem.
|
| |
|
|
|
|
|
| |
Remove all supporting code for Windows 9x and Windows NT. The
minimum supported version is Windows 2000 now.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There doesn't seem to be a mechanism to clone FileFind handles on
Windows. Therefore this implementation just reads all remaining
entries into a cache buffer and closes the handle. All further
readdir() requests will be fulfilled from the cache buffer, in both
the original and the new interpreter.
This fixes bug 75154 on Windows (all tests in t/op/threads-dirh.t pass).
This commit also changes the return value of win32_telldir() to -1
for directory handles that have been read until the end. The previous
return value was (NULL - dirp->start), which technically is not
valid C code.
API change alert: Perl_dirp_dup() gets an additional CLONE_PARAMS
parameter in this change (like all the other Perl_*_dup() functions).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Here's a patch that removes an unnecesary call to win32_stat() by
the opendir code on Win32. This provides a noticeable speed up when
recursively traversing a directory eg. calls to File::Find::find().
Note it does change behaviour in the following cases:
1. The patch makes directory names longer than MAX_PATH fail and
sets errno to ENAMETOOLONG ("Filename too long"). Currently, in
this case errno is not actually set in win32_opendir.
2. If the directory is actually a regular file then currently errno
is not set, and so (as in case 1) errno ends up being set to EBADF.
The patched version will 'fail' via the same code path as if it's
just a non existant file/directory name (FindFirstFile will return
ERROR_PATH_NOT_FOUND) and so errno gets set to ENOENT.
|
|
|
|
|
|
|
|
| |
Commit 827da6a38 added a custom isatty() implementation
in win32/perlhost.h, but that code will only be used when
perl is compiled with -DPERL_IMPLICIT_SYS. This change
makes sure that the custom implementation will be used
on Windows for all choices of build options.
|
|
|
|
|
| |
(We only #define SET_INVALID_PARAMETER_HANDLER for VC2005 and later, so
users of earlier compilers will not have seen this error)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
settings for Windows Vista and later. Without this setting Windows
will treat perl.exe as a legacy application and apply various
heuristics like redirecting access to protected file system areas
(like the "Program Files" folder) to the users "VirtualStore"
instead of generating a proper "permission denied" error.
For VC8 and VC9 this manifest setting is automatically generated by
the compiler/linker (together with the binding information for their
respective runtime libraries); for all other compilers we need to
embed the manifest resource explicitly in the external resource file.
This change also requests the Microsoft Common-Controls version 6.0
(themed controls introduced in Windows XP) via the dependency list
in the assembly manifest. For VC8 and VC9 this is specified using the
/manifestdependency linker commandline option instead.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The winsock error codes from WSAGetLastError() are stored by
Perl in errno, and there is some code in win32_strerror() that
would stringify them, but that code is never called when Perl
is built with the default WIN32IO_IS_STDIO setting.
This patch enables the win32_strerror() override unconditionally
and also fixes a potential memory corruption issue by using
the FORMAT_MESSAGE_IGNORE_INSERTS flag to ignore any parameter
substitution codes that may be embedded in the error message.
This now works as expected:
C:\git\perl>perl -Ilib -MPOSIX -E "$!=POSIX::EWOULDBLOCK; say $!"
A non-blocking socket operation could not be completed immediately.
|
|
|
|
|
|
|
|
|
|
|
|
| |
It used to set errno to GetLastError(), which is from an
incompatible set of error codes. That doesn't make any
sense, especially since the GetLastError() value is also
available at the Perl level via $^E.
It is important for autodie.pm that flock() will set
$! to WSAWOULDBLOCK when GetLastError() returns
ERROR_LOCK_VIOLATION because that is the value POSIX.pm
now returns for POSIX::EWOULDBLOCK.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Hi,
Using the attached patch to the blead source (as of a few hours ago), I can
build perl with the following OS/compiler/make combos.
On 32-bit XP:
MSVC++ 7.0 / dmake (uses win32/makefile.mk)
MSVC++ 7.0 / nmake (uses win32/Makefile)
Borland C++ 5.5.1 / dmake
mingw.org's gcc-4.3.0 / dmake
mingw.org's gcc-3.4.5 / dmake
mingw-w64.sf's 32-bit gcc-4.4.3 / dmake
(There's a bug with that last compiler on XP.
The perl it builds on XP hangs on XP, but runs ok if copied across to Vista.
I think this is unrelated to the patches - probably even unrelated to perl.
Without these patches perl will not even build using that last compiler.)
On 64-bit Vista:
32-bit MSVC++ 7.0 / nmake (uses win32/Makefile)
32-bit MSVC++ 7.0 / dmake (uses win32/makfile.mk)
32-bit Borland C++ 5.5.1 / dmake
mingw.org's 32-bit gcc-4.4.0 / dmake
mingw.org's 32-bit gcc-3.4.5 / dmake
mingw-w64.sf's 32-bit gcc-4.4.3 / dmake
mingw-w64.sf's 64-bit gcc-4.4.3 / dmake
mingw-w64.sf's 64-bit x86_64-w64-mingw32-gcc-4.4.3 / dmake
64-bit MicrosoftPlatform SDK for Windows Server 2003 R2 / dmake (uses
win32/makefile.mk)
64-bit MicrosoftPlatform SDK for Windows Server 2003 R2 / nmake (uses
win32/Makefile)
Not all of those builds pass all tests - but where the removal of the
patches still permits perl to build, the same tests still fail. That is,
*nothing* is lost by including these patches - but there are significant
gains.
Each of the above builds was done according to the normal win32
configuration parameters - ie multi-threaded, non debug. No unusual config
settings were applied. (I did build one debug perl on Vista using
mingw-w64.sf's 32-bit gcc-4.4.3 and it built fine.)
Please feel free to apply these patches (with or without modification) -
and, yes, you're more than welcome to blame me if they cause any breakages
;-)
Of course, some of those compilers (Borland, Microsoft, and the compilers
from mingw.org) already build perl *without* having to apply any patches.
It's just the other compilers that need the patches. The purpose of testing
with Borland, Microsoft, and the mingw.org compilers is just to check that
these patches don't break them.
As a final check, I've done a build on my aging linux (mandrake-9.1) box,
gcc-3.2.2. I built with '-des -Duselongdouble -Duse64bitint -Dusedevel'. No
problem with that, either.
If there's additional testing requirements please let me know, and I'll try
to oblige.
I believe the patch applied successfully for me - see below my sig for the
output.
Cheers,
Rob
Rob@desktop2 ~/GIT/blead
$ patch -p0 <blead_diff.diff
patching file dist/threads/threads.xs
patching file handy.h
patching file cpan/ExtUtils-MakeMaker/lib/ExtUtils/MM_Win32.pm
patching file op.c
Hunk #1 succeeded at 5774 (offset 47 lines).
patching file pp_pack.c
patching file util.c
Hunk #1 succeeded at 5366 (offset -28 lines).
patching file win32/makefile.mk
patching file win32/perlhost.h
patching file win32/win32.c
patching file win32/win32.h
patching file README.win32
patching file XSUB.h
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If perl.exe is called with a short pathname, then GetModuleFileName()
will return this short name, and $^X will be set to it. This in turn
is used to initialize @INC to privlib, sitelib and vendorlib locations
relative to $^X, so they too will end up with the mangled short names.
Perl will also automatically add versioned Perl directories in the
same tree if their names start with the same major and minor Perl
version numbers. This heuristic can be broken when the pathname
components are using short pathnames. Therefore $^X and @INC should
all be normalized to use the long pathname format.
See also http://rt.cpan.org/Public/Bug/Display.html?id=47890
|
| |
|
|
|
|
|
|
|
| |
Subject: Re: /ext/Time-Piece/t/02core.t
From: Rob May <rob@themayfamily.me.uk>
Date: Thu, 16 Apr 2009 10:32:53 +0100
Message-ID: <54bdc7510904160232m1ae4142dw3566bf27b4fd2818@mail.gmail.com>
|
|
|
|
|
| |
That was removed long ago by #8916, but some leftovers remained. See:
http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2009-04/msg00156.html
|
|
|
|
|
| |
as we already know it, and use it in S_init_perllib() to save a strlen() in
S_incpush_use_sep().
|
|
|
|
|
|
| |
From: "Jan Dubois" <jand@activestate.com>
Message-ID: <01be01c8a9d1$12b32b10$38198130$@com>
p4raw-id: //depot/perl@33763
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
From: "Steve Hay" <SteveHay@planit.com>
Message-ID: <1B32FF956ABF414C9BCE5E487A1497E70176BD61@ukmail02.planit.group>
"OK, so how about the attached. This fixes up -w for all compilers so
that it is symmetrical with chmod(), and adds a note to perltodo on
fixing POSIX::access() and chdir()."
The whole long thread started here:
http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2008-03/msg00056.html
p4raw-id: //depot/perl@33566
|
|
|
|
|
|
| |
From: "Robert May" <rob@themayfamily.me.uk>
Message-ID: <54bdc7510803130706q6523793ak1f3f1c6578fa97c1@mail.gmail.com>
p4raw-id: //depot/perl@33506
|
|
|
|
|
| |
http://www.nntp.perl.org/group/perl.daily-build.reports/2008/02/msg53937.html
p4raw-id: //depot/perl@33370
|
|
|
|
|
|
|
|
|
|
|
|
| |
ability to create landmines that will explode under someone in the
future when they upgrade their compiler to one with better
optimisation. We've already done this at least twice.
(Yes, some of the assertions are after code that would already have
SEGVd because it already deferences a pointer, but they are put in
to make it easier to automate checking that each and every case is
covered.)
Add a tool, checkARGS_ASSERT.pl, to check that every case is covered.
p4raw-id: //depot/perl@33291
|
|
|
|
|
|
| |
From: "Robert May" <rob@themayfamily.me.uk>
Message-ID: <54bdc7510802030434g4f9da56eq8d526e80c297290b@mail.gmail.com>
p4raw-id: //depot/perl@33255
|
|
|
|
|
|
| |
From: "Robert May" <robertmay@cpan.org>
Message-ID: <54bdc7510802022341r3654d32dva26ef04bd9fa04b7@mail.gmail.com>
p4raw-id: //depot/perl@33254
|
|
|
|
|
|
| |
system specific directories. I think I've chainsawed all of them now,
but I can't guarantee that it compiles anywhere from win32.
p4raw-id: //depot/perl@32713
|
|
|
|
|
|
|
|
|
|
|
| |
From: "Jan Dubois" <jand@activestate.com>
Message-ID: <02bd01c7b90b$49863720$dc92a560$@com>
Rearranges the initialization of Win32CORE. The Perl interpreter isn't
fully initialized when Perl_init_os_extras() in win32/win32.c is called,
so it is not safe to use the Perl calling mechanism yet. Fixes a problem
building PAR-Packer on Win32.
p4raw-id: //depot/perl@31490
|
|
|
|
|
| |
because it now isn't used anywhere.
p4raw-id: //depot/perl@31356
|
|
|
|
|
|
|
|
| |
section, where it didn't belong. (That section should (currently)
only contain sys_intern_init(), sys_intern_clear() and
sys_intern_dup() and related functionality such as
win32_csighandler().)
p4raw-id: //depot/perl@31354
|
|
|
|
|
|
|
|
|
|
| |
by /OPT:REF" by removing the only reference to a SHELL32.dll function
(namely, CommandLineToArgvW(), called from win32_argv2utf8(), which
isn't actually used anywhere so delete it).
That then caused the warning "/DELAYLOAD:shell32.dll ignored; no
imports found from shell32.dll", so remove that /DELAYLOAD option too.
p4raw-id: //depot/perl@31347
|
|
|
|
|
|
| |
From: "Jan Dubois" <jand@activestate.com>
Message-ID: <02d101c79434$743be100$5cb3a300$@com>
p4raw-id: //depot/perl@31211
|
|
|
|
|
|
|
|
| |
Message-ID: <20070503213923.GH24804@iabyn.com>
Fixes the failure to kill a pseudo-forked child on Win32 described in
[perl #42869], but the "Free to wrong pool" error remains
p4raw-id: //depot/perl@31188
|
|
|
|
|
|
| |
From: "Jan Dubois" <jand@activestate.com>
Message-ID: <01e301c7808a$ac0cca30$04265e90$@com>
p4raw-id: //depot/perl@30979
|
|
|
|
|
|
|
|
| |
From: "Jan Dubois" <jand@activestate.com>
Message-ID: <01df01c78088$59718d30$0c54a790$@com>
Fixes breakage caused by #29605.
p4raw-id: //depot/perl@30970
|
|
|
|
|
| |
Message-ID: <4kll13df3tndn8alp54gi9ur9jmq063aij@4ax.com>
p4raw-id: //depot/perl@30878
|
|
|
|
|
|
|
|
|
|
| |
From: "Yitzchak Scott-Thoennes" <sthoenna@efn.org>
Message-ID: <1254.67.42.109.122.1171965018.squirrel@67.42.109.122>
Also includes integration & deletion of win32/ext/Win32API to
ext/Win32API, and addition of copyright message and corrections to
spacing/tabbing as suggested by Jan Dubois.
p4raw-id: //depot/perl@30379
|
|
|
|
|
|
| |
From: "Devin Heitmueller" (via RT) <perlbug-followup@perl.org>
Message-ID: <rt-3.6.HEAD-1834-1169505975-229.41318-75-0@perl.org>
p4raw-id: //depot/perl@29930
|
|
|
|
|
| |
Message-ID: <rigoq25vda3sg4i7ppdb5o2jhvuiq15kqj@4ax.com>
p4raw-id: //depot/perl@29868
|
|
|
|
|
|
|
|
| |
Message-ID: <eei5q29hrchpam2i5g0000mbvu0b1hrm83@4ax.com>
Fixes the Borland build, in which the PATH was getting corrupted
when the variable that was just putenv()'d got free()'d
p4raw-id: //depot/perl@29732
|
|
|
|
|
| |
p4raw-link: @29708 on //depot/perl: 2ba2769ea20cab9d830589a267b2b38118c75056
p4raw-id: //depot/perl@29728
|
|
|
|
|
| |
Message-ID: <9b18b3110701071151y13eaa554w257d2d5016ee0983@mail.gmail.com>
p4raw-id: //depot/perl@29708
|
|
|
| |
p4raw-id: //depot/perl@29692
|
|
|
|
|
| |
Message-ID: <7coqp2pme3r30qaonticuv6c6licieg4cg@4ax.com>
p4raw-id: //depot/perl@29690
|
|
|
|
|
| |
Message-ID: <f2oqp2dbdglim8bda4q1kajt9k3cvpqqga@4ax.com>
p4raw-id: //depot/perl@29689
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
represented in the current codepage
Date: Thu, 28 Dec 2006 18:59:40 -0800
Message-ID: <vq09p2p09k6rcu6c9t0mab3vnc335ghg9m@4ax.com>
Subject: Re: [PATCH] Use short pathnames in $^X and @INC if the long form cannot be represented in the current codepage
From: Jan Dubois <jand@ActiveState.com>
Date: Wed, 03 Jan 2007 08:12:35 -0800
Message-ID: <orknp2pj17265modfosjkp2qtt4bdgtgjp@4ax.com>
p4raw-id: //depot/perl@29675
|
|
|
|
|
| |
Message-ID: <m8hjo2pasv3hdbhd1sj9sasen7tm38hrhp@4ax.com>
p4raw-id: //depot/perl@29605
|
|
|
|
|
|
|
| |
outside the current codepage
Message-ID: <8nmgo2dr5gtmv00gtfu07g7rdgitr859jk@4ax.com>
p4raw-id: //depot/perl@29597
|
|
|
|
|
|
|
|
|
|
| |
Date: Mon, 11 Dec 2006 13:09:09 -0800
Message-ID: <isfrn2tbfleo1svmmi5kh673f4uh69am11@4ax.com>
and:
Date: Mon, 11 Dec 2006 15:08:53 -0800
Message-ID: <kvorn2h0d14jo3khmmj2a9svsp2mplrodv@4ax.com>
p4raw-id: //depot/perl@29528
|
|
|
|
|
| |
Message-ID: <9moon29qtn5c23t9fer229ealsu06bkf11@4ax.com>
p4raw-id: //depot/perl@29511
|