summaryrefslogtreecommitdiff
path: root/win32/win32.h
Commit message (Collapse)AuthorAgeFilesLines
* Move the VC6 "broken-nan" define from win32.h to perl.h.Jarkko Hietaniemi2014-09-231-6/+0
|
* On VC6 (broken NaN compare) redefine Perl_isinf.Jarkko Hietaniemi2014-09-201-1/+2
| | | | | | | So that it works with NaN, by not using the comparison version of Perl_isinf. A little messy but since win32/win32.h is included so late in perl.h, cannot be done earlier with the other Perl_isinf logic. Partially reverts 128eeacb.
* speed up miniperl require on Win32Daniel Dragan2014-04-081-0/+3
| | | | | | These 3 optimizations reduce the number of, usually failing, I/O calls for each "require" for miniperl only. None are appropriate except for Win32. See #121119 for details.
* fix killpg on Win32, to meet posix expectations for killpgDaniel Dragan2014-03-271-1/+0
| | | | | | | | | | | | | | | | On Win32 Perls built without PERL_IMPLICIT_SYS, killpg from win32.c was directly called by Perl_apply, yet killpg's return value had Win32 behavior, not POSIX behavior. Modify killpg token to have same meaning as PerlProcKillpg/PerlProc_killpg has on PERL_IMPLICIT_SYS builds. Use a macro rather than create a win32_killpg C function since win32_killpg would be nothing but a call to win32_kill anyways. win32_kill contains the Win32 to POSIX semantics conversion code. Rename old killpg to my_killpg since it has no use outside of win32.c. The psuedo-PID code in win32_kill also played a factor in not writing a separate win32_killpg that calls my_killpg. This fix is tested by kill0.t passing on no-PERL_IMPLICIT_SYS builds. [perl #121230]
* fix missing _rotl64 symbol on Visual C 2003Daniel Dragan2014-01-091-0/+5
| | | | | | | | | Due to a bug in the CRT (msvcr71.dll), these 2 functions are not defined in any lib Perl can use (static link CRTs dont apply, Perl only uses DLL CRTs), but they are available as intrinsics. This solves a link error about missing symbol __rotl64 in hv.obj, from usage in hv_func.h, on 32 bit USE_64_BIT_INT VC 2003 builds. _rotr64 is included for completeness. This fix is filed as [perl #120925].
* win32/win32sck.c: dont close() a freed socket os handleDaniel Dragan2013-11-021-0/+94
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch is in RT as [perl #120091] but also fixes [perl #118059]. Because the MS C lib, doesn't support sockets natively, Perl uses open_osfhandle, to wrap a socket into CRT fd. Sockets handles must be closed with closesocket, not CloseHandle (which CRT close calls). Undefined behavior will happen otherwise according to MS. Swap the now closed socket handle in the CRT to INVALID_HANDLE_VALUE. The CRT will not call CloseHandle on INVALID_HANDLE_VALUE and returns success if it sees INVALID_HANDLE_VALUE. CloseHandle will never be called on a socket handle with this patch. In #118059, a race condition was reported, where accept() failed with ENOTSOCK, when a psuedofork was done, and connection from the child fake perl process to parent fake perl process was done. The race condition's effects occur inside the user mode code in mswsock.dll!_WSPAccept in the parent perl, which winds up having a kernel handle of an unknown type in it that is invalid. The invalid handle is passed to kernel calls, which fail, because the handle is invalid, and the error is translated to ENOTSOCK. The exact mechanism of the bug and 100% reproducabilty of the race were never established, since mswsock.dll is closed source. Another benefit of this patch is making it easier to use C debuggers on a Win32 Perl because of less debugger-only bad handle exceptions (NtGlobalFlag FLG_ENABLE_HANDLE_EXCEPTIONS/0xC0000008 STATUS_INVALID_HANDLE). This commit reverts parts of commit 9b1f18150a "Get rid of PERL_MSVCRT_READFIX" and parts of commit 46e77f1118 "Don't use the PERL_MSVCRT_READFIX when using VC++ 7.x onwards." and contains additional changes not found in those 2 commits. The method for selecting the definition of struct ioinfo isn't perfect. It will break if VC > 6 is changed to use the older msvcrt.dll. For some versions of the CRT, like 2005/8.0, it is impossible to know the definition of ioinfo struct at C compile time, since the struct increased in size a number of times with higher build numbers of v8.0 CRT. SxS and security updates make that same perl binary will run with different v8.0 CRTs at different times. For the case when ioinfo can not be hard coded, introduce WIN32_DYN_IOINFO_SIZE. With WIN32_DYN_IOINFO_SIZE, the size of the ioinfo struct is determined on Perl process startup using _mize. Since VC 2013 is a brand new product at the time of this patch, even though its struct is known, and 2008 through 2012 have been stable so far, don't assume at this time 2013's ioinfo will be stable. Therefore, VC 2003 and older (including Mingw's v6.0), 2008 to 2012, are hard coded. 2013 is a candidate one day to be hard coded. VC 2005 can never be hard coded. All non-WIN32_DYN_IOINFO_SIZE compilers will work with WIN32_DYN_IOINFO_SIZE. Non-WIN32_DYN_IOINFO_SIZE mode is simply more efficient. For future compatibility concerns, 3 forms of protection are offered. If __pioinfo isn't exported anymore, the Perl build will break. In WIN32_DYN_IOINFO_SIZE mode, if __pioinfo isn't heap memory anymore or the start of a memory block, the runtime panic will happen. In with and without WIN32_DYN_IOINFO_SIZE, only on a DEBUGGING build, the handle returned by CRT's _get_osfhandle, which is the authentic handle in the CRT, is compared to the handle found by accessing the ioinfo struct directly. If they don't match, the handle swapping code is broken and the assert fails.
* Add support for building with Visual C++ 2013Steve Hay2013-10-221-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Two tests (t/io/fs.t and cpan/HTTP-Tiny/t/110_mirror.t) fail on my system, currently in Daylight Saving Time, both due to times written/read by utime()/stat() being off by one hour... Not sure what the issue is yet, but I've reproduced it in this C program: #include <stdio.h> #include <sys/stat.h> #include <sys/utime.h> void main(void) { struct _utimbuf ut; struct _stat st; time_t t; t = 760060800; printf("Setting: %ld\n", t); ut.actime = t; ut.modtime = t; if (_utime("test.c", &ut) == -1) { perror("_utime failed\n"); return; } if (_stat("test.c", &st) != 0) { perror("_stat failed\n"); return; } printf(" atime: %ld\n", st.st_atime); printf(" mtime: %ld\n", st.st_mtime); } which outputs Setting: 760060800 atime: 760057200 mtime: 760057200 with VC++ 2013, instead of Setting: 760060800 atime: 760060800 mtime: 760060800 like Visual C++ 6.0 through 2012 all do.
* WinCE Makefile and make_ext.pl general and XS fixesDaniel Dragan2013-10-211-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On a WinCE build. On the 2nd nmake run, using Makefile.ce, eventually calls the Extensions target which calls make_ext.pl. What happens is nmake for CE for each module is called on the Desktop per module makefile from the earlier Desktop build. Since the Desktop Perl already was built sucessfully, all rules/deps are met in the Desktop per module makefile, and nothing happens during the module building phase for a CE build. Previously I used external file management tools to delete the per module Makefiles before running Makefile.ce. *make_ext.pl - implement deleting and rebuilding the per module makefile on a Cross build - use constants for constant folding, there are opportunities for other variables to be converted to constants in the future - fix a bug from commit baff067e71 where unlink() on a file with an open handle ($mfh) didn't delete the file from disk and a new per module makefile would be not be built by make_ext.pl later since the per module makefile was still on disk. This was observed on Win32. Also harden the unlink code with a new _unlink sub that is fatal if the file is still on disk after unlink supposedly deleted it. - var $header and the quotemeta is because of an issue in Perl #119793 *Makefile.ce - bring the debugging symbol generation flags and optimization flags to be closer to a Dekstop VC Perl build - ICWD is obsolete as of commit f6b3c354c9 , remove it - MINIMOD is obsolete as of commit 7b4d95f74b , remove it - make a poisoned config.h so if there is a XS building mixup between a desktop and CE perl, the poisoned config.h for CE will stop the build gracefully - $(MINIPERL) has never been defined in Makefile.ce from day 1 (10 years) replace with $(HPERL) everywhere, this was causing things to not run silently since $(MINIPERL) was empty string. Use HPERL instead of MINIPERL to allow flexibility to use the full perl binary if necessery one day - better cleaning on root makefile clean target *win32/win32.h *win32/win32iop.h - silence alot of redefinition warnings which gave pages of warnings on each WinCE compliand *mg.c - win32_get_errno is only on WIN32 build not WINCE a "nmake -f Makefile.ce all" will now build the CE interp and all modules in 1 shot with no user intervention
* Add a USING_MSVC6 macro to identify Microsoft Visual C++ 6.0Steve Hay2013-09-191-1/+1
| | | | | | | This simplifies some of the logic necessary for coping with its various problems. Suggested by Nicholas Clark.
* Intercept assignment to $! to translate WSAExxx values to Exxx values on WindowsSteve Hay2013-09-161-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | Since perl previously assigned WSAExxx values to $! on Windows it is quite possible that (Perl-level) user code may also manually make similar assignments, which will now cause breakage if the value put in $! is subsequently compared to Errno/POSIX constants because the latter are now the corresponding Exxx values where possible. An example of this is in Net::Ping::tcp_connect(), which does the following to fetch a socket-level error code: unpack("i", getsockopt($self->{"fh"}, SOL_SOCKET, SO_ERROR)) and assigns the result (a WSAExxx value such as 10061) to $! and then goes wrong in the subsequent test (in ping_tcp()) for $! == ECONNREFUSED (which is now 107 rather than 10061 if perl is built with VC10 or higher). To avoid this we now intercept assignment to $! and convert any WSAExxx values to Exxx values first. This causes a minor oddity in that this: perl -le "$! = 10061; print 0+$!" will now output 107 (for VC10+ perls) but this is surely preferable to the alternative breakage described above.
* Win32 miniperl: delay loading for Winsock, and then remove itDaniel Dragan2012-10-311-2/+36
| | | | | | | | | | | | | | | | | | | Slim down the image and speed up start up time for Win32 miniperl by removing Winsock. Also if the build process on Win32 in the future requires sockets, commenting one line in win32.h will turn sockets back on for miniperl, but this time with delay loading on VC Perl. The only casulty of no sockets for Win32 miniperl was figuring out the computer's name in win32/config_sh.PL. A workaround by using an ENV var was implemented. The purpose of this commit is to speed up the build process of Perl. As said in the comment in win32.h, the WIN32_NO_SOCKETS macro is incomplete in implementation. It is only removed winsock from being linked in in miniperl, not full Perl. PERL_IMPLICIT_SYS (specifically PerlSock in win32/perlhost.h) and makedef.pl's hard coded list of win32_* function exports cause winsock to still be linked in with even with WIN32_NO_SOCKETS on full perl. Both PERL_IMPLICIT_SYS (win32/perlhost.h) and makedef.pl would require changes to remove winsock from being linked in on full perl in the future.
* consting in perl.c:S_Internals_V and Win32 DynaLoaderDaniel Dragan2012-10-311-1/+1
| | | | | | | These assorted static allocated variables were in RW memory in the perl image. Move them to RO memory so they are sharable between different Perl processes by the OS. The lack of consting in Win32 Dynaloader traces to commit 0a753a76406 . S_Internals_V traces to commit 4a5df386486 .
* stop Win32 VC miniperl from exporting functionsDaniel Dragan2012-10-111-4/+8
| | | | | | | | | | | | | | | | | | | | miniperl.exe does not load XS modules. It has no reason to export anything. About 130 things are exported by VC Win32 miniperl. 90% of them are the win32_* functions. All but a couple Perl_* exports are gone in the exporting miniperl. See perl #115216 for the full list of accidentally exported items. Also stop trying to find Win32CORE's boot function in Perl_init_os_extras through the export table. It is not exported and not in the miniperl image and GetProcAddress will never return not NULL. By removing this GetProcAddress call, miniperl stops importing GetProcAddress from kernel32 and a tiny bit startup time by miniperl during the full perl build process. By removing the exports the compiler is free to use more random (not cdecl) calling conventions and/or optimizing away code than before. Also by removing the export entries, and the GetProcAddress import, RO strings are removed from the miniperl image. This commit only affects the VC miniperl. The Mingw miniperl remains unmodified except for not trying to load Win32CORE through the export table and some of the .c files being compiled with PERL_IS_MINIPERL when previously they were not.
* fix C++ builds broken by cdc4a174060Daniel Dragan2012-10-101-0/+5
| | | | | | | | | | | | | In commit cdc4a174060 static noreturn function, on a C++ build, (specific example, GCC ) got a post preprocessor prototype of "extern "C" static void S_fn_doesnt_return(". GCC generates a compile error if "extern "C"" and static used together. Plain C build were not affected. This commit fixed the problem by creating 2 new static exclusive macros, so extern "C" does not wind up on statics in a C++ build. The macros allow enough flexibility so any compiler/platform that needs a noreturn declaration specifier instead of a noreturn function attribute can have one.
* Remove exports of dummy set[ug]id functions on WindowsSteve Hay2012-10-051-3/+2
| | | | | | | These are surely not required by anything, and are only stub functions anyway so can easily be provided locally by anything that really does need them. Also hide the declarations other than when building the core itself as per the fix for [perl #114516].
* Remove option to build without USE_SOCKETS_AS_HANDLES on WindowsSteve Hay2012-09-281-9/+0
| | | | | | | | | The option is always defined by default and can't be disabled from the makefiles. Manually disabling it causes several tests to fail, which nobody has reported, so we presume nobody does this. The non-default configuration is believed to be historical cruft with no value now, and has clearly bitrotted in recent years (hence the test failures), so remove it to simplify the codebase slightly.
* Stop declaring non-exported externs to non-core XS modules [perl #114516]Steve Hay2012-09-261-2/+5
| | | | | | | | | | | | | | | | | | | Hide the perl.h declarations of gete?[ug]id and getlogin on Win32 since they are already declared in win32/win32.h, nearer to their definitions (stub functions for UNIX compatibility) in win32/win32.c. Also only declare them, and kill(pg)?, sbrk, chown and mkstemp, under PERL_CORE anyway since they are not exported: including declarations for non-exported functions just hides compiler errors about the symbols being undefined, which doesn't help when trying to fix subsequent errors from the linker about the symbols being unresolved. (Actually, all but sbrk, chown and mkstemp get indirected through the perlhost layer normally anyway, but it doesn't hurt to still hide the declarations, and helps in the case of PERL_IMPLICIT_SYS not being defined, where only kill is redefined to something which is exported.) The declarations of the set[ug]id stub functions remain for now because those two symbols are currently exported.
* We don't support compilers other than MS VC++ and MinGW/gcc on WindowsSteve Hay2012-08-181-8/+4
|
* Remove two unused #definesSteve Hay2012-08-181-9/+0
|
* We don't support MS VC++ < 6.0Steve Hay2012-08-181-13/+3
|
* Remove -x permission from win32/win32.hJan Dubois2012-07-301-0/+0
| | | | | | No idea why one of my previous commits added the bit. I blame Cygwin git and the fact that t/porting/exec-bit.t is skipped on Windows.
* Add MSVC noreturn to inside of the interpDaniel Dragan2012-07-301-0/+4
| | | | | | | 12a2785c7e86f586a05cad9ff90ce673c68c3115 only turned on MSVC noreturn for external DLL XS modules, not inside the interp (perl5**.dll). This commit fixes that. For me (bulk88), with an -O1 build, perl517.dll dropped from 1044KB to 1036KB after applying this.
* Split __declspec(dllimport,noreturn) into 2 partsJan Dubois2012-07-301-2/+2
| | | | | | | | I thought I did test commit 12a2785c with VC6 and it built without errors, but I can no longer reproduce this. Checking standard CRT headers shows common usage (e.g. for longjmp() in setjmp.h) is "__declspec(dllimport) __declspec(noreturn)", so let's use that one instead.
* Adding support for Visual C's __declspec(noreturn) function declarations to perlDaniel Dragan2012-07-181-0/+6
| | | | | | | | | This will reduce the machine code size on Visual C Perl, by removing C stack clean up opcodes and possible jmp opcodes after croak() and similar functions. Perl's existing __attribute__noreturn__ macro (and therefore GCC's __attribute__((noreturn)) ) is fundamentally incompatible with MS's implementation for noreturn functions. win32.h already has _MSC_VER aware code blocks, so adding more isn't a problem.
* The Borland Chainsaw MassacreSteve Hay2011-09-101-32/+0
| | | | | Remove support for the Borland C++ compiler on Win32, as agreed here: http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2011-09/msg00034.html
* Redefine errno values for Visual Studio 2010Steve Hay2011-03-191-11/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Perl traditionally stores WinSock error codes (values above 10000) in errno, with corresponding support for $! to stringify them properly. In Visual Studio 2010 (and presumably newer Windows SDKs) Microsoft has started to define additional errno constants in errno.h (values between 100 and 200) with conflicting names (e.g. EWOULDBLOCK). There are 2 ways to deal with this situation: 1) Redefine the errno.h constants back to the winsock values for the Errno and POSIX modules. 2) Translate the winsock error codes to the new errno constants in the socket implementation in win32/win32sck.c. Solution 1) has the advantage that any existing Perl code that has numeric error codes hard-coded in it will continue to work. Solution 2) has the advantage that XS code using external libaries can set errno to the new constants, and they will be handled consistently in the Perl core. It will however need additional support for other compilers and runtime libraries that don't support these new error codes. This commit implements solution 1). Blame attribution: the commit message is from Jan Dubois, the actual patch was created by Steve Hay. Signed-off-by: Jan Dubois <jand@activestate.com>
* Hang on to child handle after signalling SIGTERMJan Dubois2011-03-151-11/+4
| | | | | | | This is a refinement of commit 3aa0ac5aa. We still want to hang on to the mapping between pseudo-process and thread handle, so that we can still waitpid() after signalling SIGTERM. We just don't want to wait implicitly on the signalled process anymore.
* Always build with crypt() support on WindowsJan Dubois2010-12-071-2/+0
| | | | | | | | 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.
* Get rid of PERL_MSVCRT_READFIXJan Dubois2010-12-061-53/+0
| | | | | | | 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.
* Windows 95 Chainsaw MassacreJan Dubois2010-12-021-18/+3
| | | | | Remove all supporting code for Windows 9x and Windows NT. The minimum supported version is Windows 2000 now.
* Don't use "dllimport" for code in perl5xx.dllJan Dubois2010-10-181-1/+10
| | | | | | | | | | | | | | This makes a difference for extensions that are "statically" linked into the Perl library, like DynaLoader and Win32CORE. The MinGW compiler/linker cannot resolve symbols that have been annotated as "dllimport" but are actually defined inside the same library. An exception is needed for the ext/re extension, which redefines core APIs internally, so these functions must not be marked as "dllimport" either. This commit is a fix/enhancement to commit ad6ab6c5.
* Use __declspec(dllimport) for XS code on WindowsJan Dubois2010-10-151-0/+8
| | | | | | | | | | | | By default C compilers will generate direct call instructions that the linker will have to route trhough a call thunk if the call site is not available at link time. By annotating all imported symbols the compiler is able to generate a indirect call instruction directly. This should improve performance minimally, but will also make sure the Perl API functions have the same addresses inside the core and inside XS modules. The ext/XS-APItest/t/call_checker.t tests rely on being able to compare function addresses.
* Don't redefine isnan() macro if MinGW already defined one.Jan Dubois2009-12-011-0/+2
|
* Add mingw64 supportSisyphus2009-11-091-0/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
|
* Add a parameter to win32_get_{priv,site,vendor}lib(), to return the length,Nicholas Clark2009-02-201-3/+3
| | | | | as we already know it, and use it in S_init_perllib() to save a strlen() in S_incpush_use_sep().
* Fix bit-fields for VC [was RE: [perl #50386] GIMME_V broken with 5.10.0/GCC ↵Jan Dubois2008-02-121-0/+8
| | | | | | | | and XS?] From: "Jan Dubois" <jand@activestate.com> Message-ID: <02ee01c8651b$17ef72f0$47ce58d0$@com> p4raw-id: //depot/perl@33292
* Stop VC++ from warning "all references to 'SHELL32.dll' discardedSteve Hay2007-06-071-1/+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
* Fix the ext/IO/t/io_sock.t failure when built with VC++ 2005Steve Hay2007-05-251-2/+5
| | | | | | | | | | | | | Unknown to me win32/win32.h was defining USE_FIXED_OSFHANDLE, which arranged for a black magic fix to MSVCRT.DLL's _open_osfhandle() to be used. It seems that this is inappropriate for VC++ versions later than 6.x, since they don't use that DLL: simply not defining that symbol makes the io_sock.t failure go away. (Compare change #29233, which similarly disabled the fix to MSVCRT.DLL's read() for VC++ versions later than 6.x.) p4raw-link: @29233 on //depot/perl: 46e77f111828d72136c91f0837803182535da01d p4raw-id: //depot/perl@31271
* RE: When is -DPERL_CORE required?Jan Dubois2007-05-201-4/+0
| | | | | | From: "Jan Dubois" <jand@activestate.com> Message-ID: <044601c79976$046691d0$0d33b570$@com> p4raw-id: //depot/perl@31242
* Implement killpg() for MSWin32Jan Dubois2006-12-211-0/+1
| | | | | Message-ID: <m8hjo2pasv3hdbhd1sj9sasen7tm38hrhp@4ax.com> p4raw-id: //depot/perl@29605
* Don't use the PERL_MSVCRT_READFIX when using VC++ 7.x onwards.Steve Hay2006-11-081-9/+0
| | | | | | | | | | VC++ 7.x onwards use their own MSVCR7x.dll, MSVCR8x.dll, etc, rather than MSVCRT.dll, so they do not require the read() fix. Therefore, we also don't need to update the ioinfo struct used by the read() fix w.r.t. VC++ 8.x, so back out that part of change #29218 p4raw-link: @29218 on //depot/perl: 0448a0bdbfbd5e00696d6b3361b97fb1190434c1 p4raw-id: //depot/perl@29233
* Get Visual C++ 2005 (aka Visual C++ 8.x) support off the groundSteve Hay2006-11-061-0/+9
| | | | | | | | | | | | | 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
* Silence some more Borland compiler warningsSteve Hay2006-08-301-8/+9
| | | | | | | | | | | (See: http://www.nntp.perl.org/group/perl.daily-build.reports/40471) - Change the cryptic pragma warn strings into numbers that are more easily recognized, and add a new one (8027). - Add a similar pragma warn line to fcrypt.c, which doesn't use win32.h. p4raw-id: //depot/perl@28769
* Silence a couple of Borland compiler warningsSteve Hay2006-08-011-1/+1
| | | p4raw-id: //depot/perl@28643
* RE: [PATCH-for-28089] wince yet another stepVadim Konovalov2006-05-041-1/+1
| | | | | | From: "Konovalov, Vadim Vladimirovich (Vadim)** CTR **" <vkonovalov@Lucent.com> Message-ID: <E3FB32585BF1D411B9E900805FF51A0801BCB454@ru0022exch001u.ru.lucent.com> p4raw-id: //depot/perl@28100
* Re: Merge WinCE into Win32 directory and remove the the WinCE directoryYves Orton2006-05-021-0/+7
| | | | | | | | Message-ID: <9b18b3110605011002m56c0db99n169ae677efb6d059@mail.gmail.com> Plus adjustements to MANIFEST. Also, perlmain.c seemed to be missing from the patch. p4raw-id: //depot/perl@28061
* Sigh. Third time lucky.Steve Hay2006-05-021-2/+2
| | | p4raw-id: //depot/perl@28053
* Ahem. And here's the rest of #28051...Steve Hay2006-05-021-0/+2
| | | p4raw-id: //depot/perl@28052
* Merge WinCE and Win32 directories -- Initial patchYves Orton2006-04-281-0/+12
| | | | | Message-ID: <9b18b3110604271430k4de84685jec6535ded195ed94@mail.gmail.com> p4raw-id: //depot/perl@28003
View Lorry Controller Status