summaryrefslogtreecommitdiff
path: root/win32
Commit message (Collapse)AuthorAgeFilesLines
* Bump the version to 5.17.6Florian Ragwitz2012-10-193-3/+3
|
* Add a new perldeltaFlorian Ragwitz2012-10-193-4/+8
|
* add PERL_CALLCONV_NO_RET to perlhost.h's PerlProcExit and PerlProc_ExitDaniel Dragan2012-10-171-2/+2
| | | | This gives noreturn to the 2 functions on Visual C Perl.
* win32_freeenvironmentstrings: convert nonpublic exported function to macroDaniel Dragan2012-10-172-7/+7
| | | | | | | | | win32_freeenvironmentstrings was added in commit 4f46e52b008. It is not documented as public api but is exported. Since it is nothing more than a renaming of win32_free, replace it with a macro to win32_free. This saves an entry in the export table, and the string name of the export from perl517.dll. Also see http://www.nntp.perl.org/group/perl.perl5.porters/2012/09/msg192954.html
* Add references to perl5143deltaDominic Hargreaves2012-10-121-0/+4
|
* stop Win32 VC miniperl from exporting functionsDaniel Dragan2012-10-114-6/+12
| | | | | | | | | | | | | | | | | | | | 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.
* Add extern "C" to definitions of four win32_ functionsSteve Hay2012-10-102-9/+8
| | | | | This makes them match their declarations in perlhost.h, which fixes linker errors when linking perl5XX.dll in a C++ build with VC.
* Add $(EXTRACFLAGS) to $(CFLAGS) for MinGW/gcc build on WindowsSteve Hay2012-10-101-1/+1
| | | | | | | This is useful if anything is ever put into $(EXTRACFLAGS) (e.g. I'm currently experimenting with optionally putting $(CXX_FLAG) into it for a C++ build), and is already done in the VC case (here, and in win32/Makefile).
* Minor tidy-ups from 624a1c42c1Steve Hay2012-10-101-19/+19
| | | | | Fix indents and update comments to reflect the fact that the compiler's msvcr*.dll is now used rather than loading msvcrt.dll too.
* clean up vmem.h, remove unused instrumentation hooksDaniel Dragan2012-10-101-41/+30
| | | | | | | | | | | | Removed virtual. Removed dyn loading msvcrt.dll and function pointers. Replaced with Compiler's native CRT's malloc. Moved the CS parts into _USE_LINKED_LIST blocks. There is nothing to protect if we aren't putting headers on. Faster startup time is the result of this commit. Before .text be8df .rdata 21171, after .text be88f .rdata 21121. I did turn off _USE_LINKED_LIST as an experiment, it compiled successfully and passed the /t/op/*.t tests (only ones I performed). I did not try the Knuth stuff. See also this msg by Jan Dubois https://rt.perl.org/rt3/Ticket/Display.html?id=88840#txn-1144384
* Fixes to enable building win32 files as C++ with VCSteve Hay2012-10-102-15/+15
| | | | | Mostly providing explicit casts where required by VC with /TP option, plus one renamed variable (can't have a variable called 'new' in C++).
* 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-284-89/+3
| | | | | | | | | 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.
* Remove the MPE/iX port.Nicholas Clark2012-09-212-12/+10
| | | | | MPE/iX was a business-oriented minicomputer operating system made by Hewlett-Packard. Support from HP terminated at the end of 2010.
* 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.
View Lorry Controller Status