summaryrefslogtreecommitdiff
path: root/win32/win32.c
Commit message (Collapse)AuthorAgeFilesLines
* [perl #71714] Remove redundant stat from Win32's opendir()Alex Davies2010-09-291-5/+16
| | | | | | | | | | | | | | | | | | 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.
* Implement win32_isatty()Jan Dubois2009-12-171-0/+21
| | | | | | | | 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.
* Fix code-before-declaration error on Win32 with recent VC++ compilersSteve Hay2009-11-231-10/+10
| | | | | (We only #define SET_INVALID_PARAMETER_HANDLER for VC2005 and later, so users of earlier compilers will not have seen this error)
* Always add a manifest resource to perl.exe to specify the <trustInfo>Jan Dubois2009-11-201-0/+11
| | | | | | | | | | | | | | | | | | 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.
* Support $! stringification of socket error codes on Windows.Jan Dubois2009-11-131-6/+8
| | | | | | | | | | | | | | | | | 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.
* flock() on Windows should set proper errno numbers.Jan Dubois2009-11-121-10/+21
| | | | | | | | | | | | 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.
* Add mingw64 supportSisyphus2009-11-091-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Remove broken links for hip communications inc.Leon Brocard2009-09-131-1/+1
|
* On Windows normalize $^X using GetLongPathName()Jan Dubois2009-08-111-0/+12
| | | | | | | | | | | | | | | 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
* Remove all the 5005threads specific mutex macros, which are now vestigial.Nicholas Clark2009-05-211-5/+0
|
* Add reference to MS KB article describing leak in putenv()Steve Hay2009-04-171-1/+2
| | | | | | | 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>
* Remove last vestiges of USE_WIN32_RTL_ENVSteve Hay2009-04-171-1/+2
| | | | | 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
* Add a parameter to win32_get_{priv,site,vendor}lib(), to return the length,Nicholas Clark2009-02-201-19/+24
| | | | | as we already know it, and use it in S_init_perllib() to save a strlen() in S_incpush_use_sep().
* Win32 process ids can have more than 16 bitsJan Dubois2008-04-291-4/+2
| | | | | | From: "Jan Dubois" <jand@activestate.com> Message-ID: <01be01c8a9d1$12b32b10$38198130$@com> p4raw-id: //depot/perl@33763
* RE: [PATCH revised] Fix ExtUtils::Install under CygwinSteve Hay2008-03-251-2/+15
| | | | | | | | | | | | | 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
* [perl #51674] op/alarm.t hangs on 5.11.0 (Windows Vista only)Robert May2008-03-131-2/+1
| | | | | | From: "Robert May" <rob@themayfamily.me.uk> Message-ID: <54bdc7510803130706q6523793ak1f3f1c6578fa97c1@mail.gmail.com> p4raw-id: //depot/perl@33506
* Silence Borland compiler warnings (except for warnings from zlib) here:Steve Hay2008-02-251-5/+5
| | | | | http://www.nntp.perl.org/group/perl.daily-build.reports/2008/02/msg53937.html p4raw-id: //depot/perl@33370
* assert() that every NN argument is not NULL. Otherwise we have theNicholas Clark2008-02-121-0/+10
| | | | | | | | | | | | 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
* Give Win32 message windows proper window proceduresRobert May2008-02-081-58/+183
| | | | | | From: "Robert May" <rob@themayfamily.me.uk> Message-ID: <54bdc7510802030434g4f9da56eq8d526e80c297290b@mail.gmail.com> p4raw-id: //depot/perl@33255
* win32_async_check() doesn't loop enough.Robert May2008-02-081-1/+1
| | | | | | From: "Robert May" <robertmay@cpan.org> Message-ID: <54bdc7510802022341r3654d32dva26ef04bd9fa04b7@mail.gmail.com> p4raw-id: //depot/perl@33254
* Nullch and others were still alive and well in some of the operatingSteve Peters2007-12-231-26/+26
| | | | | | 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
* RE: Problem in Win32CORE when building PAR-Packer-0.975 with bleadperl on Win32Jan Dubois2007-06-281-8/+10
| | | | | | | | | | | 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
* Change 31347 should also have removed win32_free_argvw()Steve Hay2007-06-081-10/+0
| | | | | because it now isn't used anywhere. p4raw-id: //depot/perl@31356
* Move win32_create_message_window() out of #ifdef HAVE_INTERP_INTERNSteve Hay2007-06-081-13/+12
| | | | | | | | 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
* Stop VC++ from warning "all references to 'SHELL32.dll' discardedSteve Hay2007-06-071-26/+0
| | | | | | | | | | 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
* Restore Windows NT supportJan Dubois2007-05-131-7/+13
| | | | | | From: "Jan Dubois" <jand@activestate.com> Message-ID: <02d101c79434$743be100$5cb3a300$@com> p4raw-id: //depot/perl@31211
* Re: [perl #42869] Problem killing a pseudo-forked child on Win32David Mitchell2007-05-101-0/+1
| | | | | | | | 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
* Allow sending SIGINT to child processes on Windows *if* they are running PerlJan Dubois2007-04-191-0/+10
| | | | | | From: "Jan Dubois" <jand@activestate.com> Message-ID: <01e301c7808a$ac0cca30$04265e90$@com> p4raw-id: //depot/perl@30979
* Fix kill(0, $pid) on WindowsJan Dubois2007-04-171-3/+4
| | | | | | | | From: "Jan Dubois" <jand@activestate.com> Message-ID: <01df01c78088$59718d30$0c54a790$@com> Fixes breakage caused by #29605. p4raw-id: //depot/perl@30970
* Restore Win64 compilation with the Windows Platform SDKJan Dubois2007-04-101-3/+18
| | | | | Message-ID: <4kll13df3tndn8alp54gi9ur9jmq063aij@4ax.com> p4raw-id: //depot/perl@30878
* Re: Win32 modules & cygwinYitzchak Scott-Thoennes2007-02-221-60/+8
| | | | | | | | | | 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
* [perl #41318] Patch: win32.c typo in #define MULTIPLICITYDevin Heitmueller2007-01-231-1/+1
| | | | | | 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
* Re: [PATCH] win32_async_check() can still loop indefinitelyJan Dubois2007-01-181-1/+1
| | | | | Message-ID: <rigoq25vda3sg4i7ppdb5o2jhvuiq15kqj@4ax.com> p4raw-id: //depot/perl@29868
* Re: [PATCH] ANSIfy the PATH environment variable on WindowsJan Dubois2007-01-091-88/+89
| | | | | | | | 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
* Revert change #29708 (useless)Rafael Garcia-Suarez2007-01-091-3/+0
| | | | | p4raw-link: @29708 on //depot/perl: 2ba2769ea20cab9d830589a267b2b38118c75056 p4raw-id: //depot/perl@29728
* Re: [PATCH] ANSIfy the PATH environment variable on WindowsYves Orton2007-01-071-0/+3
| | | | | Message-ID: <9b18b3110701071151y13eaa554w257d2d5016ee0983@mail.gmail.com> p4raw-id: //depot/perl@29708
* Silence various VC6 warningsSteve Hay2007-01-051-2/+1
| | | p4raw-id: //depot/perl@29692
* ANSIfy the PATH environment variable on WindowsJan Dubois2007-01-051-0/+96
| | | | | Message-ID: <7coqp2pme3r30qaonticuv6c6licieg4cg@4ax.com> p4raw-id: //depot/perl@29690
* Add error handling to win32_ansipathJan Dubois2007-01-051-19/+23
| | | | | Message-ID: <f2oqp2dbdglim8bda4q1kajt9k3cvpqqga@4ax.com> p4raw-id: //depot/perl@29689
* [PATCH] Use short pathnames in $^X and @INC if the long form cannot be ↵Jan Dubois2007-01-031-12/+100
| | | | | | | | | | | | | 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
* Implement killpg() for MSWin32Jan Dubois2006-12-211-49/+189
| | | | | Message-ID: <m8hjo2pasv3hdbhd1sj9sasen7tm38hrhp@4ax.com> p4raw-id: //depot/perl@29605
* let readdir() return the alternate (short) filename if the long name is ↵Jan Dubois2006-12-201-9/+60
| | | | | | | outside the current codepage Message-ID: <8nmgo2dr5gtmv00gtfu07g7rdgitr859jk@4ax.com> p4raw-id: //depot/perl@29597
* get ext/Win32/Win32.xs to compile on cygwinJan Dubois2006-12-121-1/+31
| | | | | | | | | | 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
* re: [PATCH] Move Win32::* functions from win32/win32.c to ext/Win32/Win32.xsJan Dubois2006-12-111-1/+2
| | | | | Message-ID: <9moon29qtn5c23t9fer229ealsu06bkf11@4ax.com> p4raw-id: //depot/perl@29511
* Second patch from:Jan Dubois2006-12-111-503/+30
| | | | | | Subject: [PATCH] Move Win32::* functions from win32/win32.c to ext/Win32/Win32.xs Message-ID: <lc9kn2tb0p5sdd4q69rbc7067r4imar59r@4ax.com> p4raw-id: //depot/perl@29510
* Re: When should PERL_SYS_TERM() be called? [was: Re: [PATCH] Re: [PATCH] Re: ↵Jarkko Hietaniemi2006-12-051-3/+2
| | | | | | | | | | | [PATCH] abstract mempool header testing] Message-ID: <4574ED1F.40508@iki.fi> Re-instates #29424 (previously reverted by #29451), now fixed to work with PERL_IMPLICIT_SYS, thanks to Jan Dubois. Also adds PERLIO_TERM to the Symbian port. p4raw-id: //depot/perl@29465
* Change #29424 may well be correct in itself, but currently doesn'tSteve Hay2006-12-041-2/+3
| | | | | | | | | | | | | | | work when perl is built with PERL_IMPLICIT_SYS because PERLIO_TERM uses PerlMemShared_free() which, in that case, involves the perlhost that has already been freed itself by perl_free(), which is called before PERL_SYS_TERM(). The order of perl_destruct(), perl_free(), PERL_SYS_TERM() cannot be changed (it is advertised in perlembed for a start), so just revert #29424 and the appropriate parts of #29442 for now. Perhaps PL_perlio_fd_refcnt needs allocating differently, or else the perlhost needs freeing later (after PerlIO)? p4raw-id: //depot/perl@29451
* I think #29060 / #29073 missed thisSteve Hay2006-11-301-0/+2
| | | p4raw-id: //depot/perl@29424
* Get Visual C++ 2005 (aka Visual C++ 8.x) support off the groundSteve Hay2006-11-061-0/+25
| | | | | | | | | | | | | This is not a complete fix yet by any means (there are lots of compiler warnings and lots of test failures), but it's a step in the right direction. See the thread starting here: http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2006-10/msg00893.html and continuing here: http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2006-11/msg00102.html for further information p4raw-id: //depot/perl@29218
* It seems only HWND__* is needed by MinGW g++.Steve Peters2006-10-301-1/+1
| | | p4raw-id: //depot/perl@29164
View Lorry Controller Status