summaryrefslogtreecommitdiff
path: root/win32
Commit message (Collapse)AuthorAgeFilesLines
* Bump the perl version to 5.17.5Florian Ragwitz2012-09-193-3/+3
|
* Add a new perldeltaFlorian Ragwitz2012-09-193-4/+8
|
* Add new warning about sleep's limitation on WindowsSteve Hay2012-09-191-1/+5
| | | | | | This also came up recently in [perl #33096]. On Windows, sleep's unsigned int argument range is effectively reduced by a factor of 1000 because the emulation uses milliseconds rather than seconds.
* Squash two win32.c warnings which have crept in recentlySteve Hay2012-09-181-3/+3
| | | | | Ensure a non-void function always returns something, and a signed/unsigned mismatch.
* Minor fixups from 001e9f8966Steve Hay2012-09-181-7/+8
|
* fix over/underflow issues in win32_msgwaitDaniel Dragan2012-09-181-11/+34
| | | | | | | | | | | This commit does not completely fix 33096, since the real problem is that VS IDE's debugger causes a Windows message to be sent to perl on each breakpoint. Depending on where the breakpoint was set. The BP may make it impossible to exit the loop because of the Visual Studio IDE Debugger's design. Various overflow and underflow issues were fixed in win32_msgwait. Specifically, the time count rolling forwards through zero (GetSystemTimeAsFileTime), and the time count running ahead of the end time (rolling backwards through zero) were fixed ("<=" check).
* Silence invalid parameter messages from win32_signalSteve Hay2012-09-111-1/+25
| | | | | | | | | | This is the first step towards enabling the invalid parameter handler without it causing undue noise. In this case the invalid parameters are intentional, so provide a means to silence messages about them. There is still noise from win32_close() and win32_select() which needs resolving by some means too before the handler can be switched on without its output causing test failures.
* ANSIfy output from invalid parameter handler, and write it to stderrSteve Hay2012-09-111-3/+31
| | | | | | | | | | | The function, file and expression are very unlikely to contain anything requiring UTF-16 output, and the output is less likely to interfere with anything when written to stderr rather than stdout. Note that the function doesn't currently do anything without hacking the makefiles because we don't currently build with _DEBUG and the debug CRT. I haven't changed that yet (other than locally) because there is actually some output from it which causes a couple of tests to fail.
* Forward declare static functions in win32/win32.cSteve Hay2012-09-111-30/+50
| | | | | This makes calling them easier without worrying about the order of definition.
* Remove the VM/ESA port.Nicholas Clark2012-08-312-6/+2
| | | | | VM/ESA was a mainframe OS. IBM ended service on it in June 2003. It was superseded by Z/VM.
* Add Configure probe for ip_mreq_sourceH.Merijn Brand2012-08-263-0/+6
| | | | Needed to upgrade Socket from CPAN
* Bump version to 5.17.4Steve Hay2012-08-203-3/+3
|
* Make new perldelta for 5.17.4Steve Hay2012-08-203-4/+8
|
* Omnibus removal of register declarationsKarl Williamson2012-08-183-13/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This removes most register declarations in C code (and accompanying documentation) in the Perl core. Retained are those in the ext directory, Configure, and those that are associated with assembly language. See: http://stackoverflow.com/questions/314994/whats-a-good-example-of-register-variable-usage-in-c which says, in part: There is no good example of register usage when using modern compilers (read: last 10+ years) because it almost never does any good and can do some bad. When you use register, you are telling the compiler "I know how to optimize my code better than you do" which is almost never the case. One of three things can happen when you use register: The compiler ignores it, this is most likely. In this case the only harm is that you cannot take the address of the variable in the code. The compiler honors your request and as a result the code runs slower. The compiler honors your request and the code runs faster, this is the least likely scenario. Even if one compiler produces better code when you use register, there is no reason to believe another will do the same. If you have some critical code that the compiler is not optimizing well enough your best bet is probably to use assembler for that part anyway but of course do the appropriate profiling to verify the generated code is really a problem first.
* We don't support compilers other than MS VC++ and MinGW/gcc on WindowsSteve Hay2012-08-184-24/+7
|
* Remove two unused #definesSteve Hay2012-08-181-9/+0
|
* We don't support MS VC++ < 6.0Steve Hay2012-08-181-13/+3
|
* Remove the UTS port.Nicholas Clark2012-08-172-6/+4
| | | | | | UTS was a mainframe version of System V created by Amdahl, subsequently sold to UTS Global. The port has not been touched since before 5.8.0, and UTS Global is now defunct.
* Tidy up comments and formatting in d903973c05Steve Hay2012-08-141-70/+77
|
* fix RT#88840, don't terminate a child fork psuedo process in DLL Loader LockDaniel Dragan2012-08-141-28/+60
| | | | | | | | | | | | | | | TerminateThread will terminate a thread but leaks all resources of that thread, and all locks will never be released, as documented in MSDN. There is no alternative to locks not being released that I see, but atleast -e "if ($pid=fork){kill(9,$pid)} else {sleep 5}" in fork.t won't deadlock with this patch since win32_start_child be reached before TerminateThread happens. The 5 ms timeout can be increased if problems arise in the future. The HWND of the child is delivered by win32_start_child very early, before any perl bytecode is executed, therefore the delay is keeping in spirit with a kill 9. In any case, if the child thread fails to schedule, (a DllMain in DLL_THREAD_ATTACH of some DLL in the process deadlocks or does very long (over 5 ms right now) sync IO), the parent interp will bail out.
* add the 5.16.1 perldeltaRicardo Signes2012-08-091-0/+4
|
* Restore parts of config_H.gc lost by regen_config_hSteve Hay2012-08-061-0/+6
|
* Run regen_config_h for GCCSteve Hay2012-08-061-1127/+1162
| | | | A few new symbols are added but no existing ones are changed.
* Run regen_config_h for VC++Steve Hay2012-08-061-1121/+1162
| | | | A few new symbols are added but no existing ones are changed.
* Add a USE_64_BIT_INT build option to the Windows makefiles.Steve Hay2012-08-018-11630/+276
| | | | | | | | | | | | | | | | | | Rather than adding more canned configurations, we dynamically set values which differ from the standard 32-bit build options, and actually remove the canned configurations for 64-bit builds too and do likewise for them. The ~ARCHPREFIX~ games used by the outgoing .gc64 configuration needed bringing into the remaining .gc configuration to maintain support for the GCCCROSS build option. Two tweaks to sv.c were required for the USE_64_BIT_INT option to work with a VC++ build, allowing the I64 printf size specification. The GCC build worked anyway since it uses ll rather than I64. The motivation for this change came from a patch submitted by Sisyphus <sisyphus1@optusnet.com.au>: Message-ID: <6AC52DD00C96415A9E919A02F12DD05F@desktop2>
* 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.
* bump to version 5.17.3Tony Cook2012-07-203-3/+3
|
* new perldeltaTony Cook2012-07-203-4/+8
|
* 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.
* Ensure wildcard expansion is enabled for perlglob.exe on WindowsSteve Hay2012-07-121-1/+15
| | | | | | | | | | | This is provided by linking in setargv.obj for Visual C++, which the makefiles already do, but for MinGW(-w64)/gcc we must explicitly ensure that wildcard expansion is enabled rather than relying on the C-runtime defaults of the particular compiler suite in question. This currently only seems to be necessary for the automated build of the MinGW-w64 cross-compiler (other builds have it enabled by default anyway), but there's no harm in making sure for others too.
* Add IP probe for ip_mreqH.Merijn Brand2012-07-115-0/+5
| | | | Backport 2f1eb816b5cba6977b1a8159
* Improve support for building on Windows with mingw-w64.sf.net binariesSteve Hay2012-07-091-7/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The cross-compiler has headers and libraries in a sub-directory called x86_64-w64-mingw32\, which is also copied to mingw\ in the automated builds but not in other builds (e.g. rubenvb's build), so rely on the folder which is always present. The DLLs required for op\taint.t to work are nomrally found in \bin\, but for the cross-compiler are found in the same folder as the libraries since they are 64-bit DLLs, whereas the compiler binaries themselves are 32-bit. With these fixes we now support the following MinGW/gcc compilers: Native 32-bit compilers (WIN64=undef GCCCROSS=undef): mingw.org, rubenvb's build of mingw-w64.sf.net, Mark Dootson's build of the same (used in Strawberry Perl). Native 64-bit compilers (WIN64=define GCCCROSS=undef): rubenvb's build of mingw-w64.sf.net, Mark Dootson's build of the same (used in Strawberry Perl). 32-bit cross-compilers producing 64-bit binaries (WIN64=define GCCCROSS=define): rubenvb's build of mingw-w64.sf.net, the automated build of the same. There is currently no automated build of a native 64-bit compiler on mingw-w64.sf.net, and their automated build of a native 32-bit compiler is not currently supported since it uses an anomalous naming convention compared to the other options above. See http://www.nntp.perl.org/group/perl.perl5.porters/2012/07/msg189461.html for discussion.
* Import CCHOME from the environment when building with GCC on WindowsSteve Hay2012-06-251-2/+1
| | | | | | | | | | | Using the environment for such things is preferable to always having to specify a CCHOME= command-line argument, and is akin to setting various environment variables via vcvars32.bat for VC++ builds. Also remove a blank line to make it more obvious that copying DLLs to the t/ folder is part of the test-prep target. (This is one thing which doesn't work if CCHOME has not been set and MinGW isn't installed in its default location.)
* bump version to 5.17.2Jesse Luehrs2012-06-203-3/+3
|
* new perldeltaJesse Luehrs2012-06-203-4/+8
|
* bump version to 5.17.1Jesse Luehrs2012-06-193-3/+3
|
* Use ll rather than I64 for win32/config*.gc64 format stringsSteve Hay2012-06-192-16/+16
| | | | | | | The corresponding types are long long rather than __int64 so this makes more sense and matches proposed diffs from the land of Strawberry Perl for supporting 32-bit builds with 64-bit ints on Windows (hopefully coming up soon...).
* Add missing dlltool default to win32/config.gcSteve Hay2012-06-191-0/+1
| | | | | ExtUtils::MakeMaker and ExtUtils::CBuilder both default to this anyway, but it's good to be explicit, and reduces diffs with the .gc64 file.
* Minor fix-ups to 4f46e52b00Steve Hay2012-06-151-4/+4
|
* Use GetEnvironmentStringsW(..) instead of GetEnvironmentStringsA(..).Karthik Rajagopalan2012-06-153-4/+41
| | | | | | | | GetEnvironmentStringsA(..) return strings in the OEM code page. This can actually mangle the environment strings if it contain special characters. A better approach would be to get the utf-16 strings through GetEnvironmentStringsW(..) and convert them to ANSI code page. This is now done by win32_getenvironmentstrings(..). To free the block, you can use win32_freeenvironmentstrings(..).
* Use standard gcc names in config_H.gc64's CPPSTDIN/CPPRUNSteve Hay2012-06-121-2/+2
| | | | | | | These canned defaults are not used in making miniperl.exe, after which the real config.h will be generated with the correct values depending on the compiler toolchain. This is just for sanity's sake to make the diff between the .gc and .gc64 files clearer.
* Fix typo in commentSteve Hay2012-06-111-1/+1
|
* Correct the comment style of a couple of not #defined symbolsSteve Hay2012-06-112-3/+3
|
* Trailing whitespace removalSteve Hay2012-06-113-3/+3
|
* MinGW/gcc does have long long, even for 32-bit buildsSteve Hay2012-06-112-2/+2
| | | | | | | (It's already used for [iu]64type and [u]quadtype, just like __int64 is used on 32-bit VC++ builds.) Thanks to Sisyphus & kmx for the spot.
* Remove win32/config*.gc64noxSteve Hay2012-06-096-5815/+18
| | | | | | | | | The ARCHPREFIX setting from makefile.mk is now passed into config_sh.PL and config_h.PL and used to apply the changes necessary to the config*.gc64 files to support both the usual gcc suite and the x86_64-w64-mingw32-gcc suite (used when GCCCROSS=define). Also remove the redundant INST_VER argument in the config_h.PL calls.
* Remove __GNUC__ / _MSC_VER games from win32/config_H.*Steve Hay2012-06-097-239/+67
| | | | | | | | | | | | | | | | | | | | | | | The code was added by 465b7da985, based on changes in ActivePerl 816, but it's not working correctly because the current build process winds up with a config.h in lib/CORE which doesn't contain that code anyway. (The appropriate canned config_H.* file is copied to config.h in order to build miniperl.exe, but then miniperl.exe is used to run config_h.PL to generate the real config.h from config_h.SH and config.sh. The real config.h is then used to build perl.exe and is what gets copied into lib/CORE for later use when building extensions, but it doesn't contain the support for other compilers because that isn't in config_h.SH...) Removing the code won't affect ActivePerl since it has not been getting installed anyway, and Jan Dubois has confirmed that it is possible to build a Perl extension using e.g. Off_t with MinGW even with the VC config.h header file. Furthermore, anyone building perl from source themselves will presumably be able to use the same compiler to build extensions as they used to build perl itself anyway, so there is no obvious need for this in the core perl distro. Therefore, removing it rather than fixing it is better for simplicity.
* Remove some commented-out lines from win32/config_h.PLSteve Hay2012-06-071-2/+0
|
View Lorry Controller Status