summaryrefslogtreecommitdiff
path: root/README.win32
Commit message (Collapse)AuthorAgeFilesLines
* Add vim-modeline to render files as PODBram2022-09-051-0/+2
| | | | | | | | | | | | GitHub (also) checks the vim-modeline to decide how the file should be rendered. These files are all in the POD format so add the vim-modeline so that GitHub displays them in a formatted way. (Note: adding `linguist-language=Pod` in .gitattributes does not work, I created a GH support ticket for that a month ago but there have been little progress on it.)
* bump version to v5.37.0Ricardo Signes2022-05-271-1/+1
|
* bump version to v5.36.0 (RC0)Ricardo Signes2022-05-201-1/+1
|
* officially support Visual C++ 2022Tomasz Konojacki2022-01-161-5/+5
| | | | No code changes are needed.
* Remove old MSVC++ (pre-VC12) support from Windows MakefilesSteve Hay2021-10-191-16/+7
| | | | | | | | | | | | | | | | | | | | Also remove the Platform SDK 2003 SP1/R2 64-bit compiler since (having just tried it) it no longer builds perl because it doesn't allow mixed code and declarations. Also remove mention of the Windows SDK since it doesn't appear to contain the compiler or linker any more. This page says that the VC++ 2010 compiler and linker were included in the Windows 7 SDK but then makes no mention of it for the Windows 8 SDK: https://docs.microsoft.com/en-us/previous-versions/visualstudio/windows-sdk/ff660763(v=vs.110) The page notes that it is no longer being updated, but the whole of the C:\Program Files (x86)\Windows Kits folder on my system (which contains 8.0, 8.10 and 10) does not contain any cl.exe or link.exe. I've re-worded some of the if/else conditions in the makefiles to pick out earlier versions rather than later versions. Thus, the current versions become the "else" case, which means that the next version of Visual C++ is more likely to work without requiring any changes.
* Update README.win32 to the new C99/MSVC 12.0 requirementsNicholas Clark2021-10-131-165/+20
| | | | | | | | | | * Remove specific notes related to Microsoft Visual C++ 2005 Express Edition and earlier * Visual Studio 2013 is the only version that still has Express edition (in addition to Community), so simplify the text by only mentioning Community * Remove the reference to IA64, and mention x86_64 along with x86 * In the context of x86_64, clarify that mingw's binaries can run on both * Update the URL for mingw
* Bump to 5.35.0:Sawyer X2021-05-211-1/+1
| | | | | | * Apparently, first you bump, then you update perldelta. * 5.35.0 *might* be released tomorrow (likely) but not certainly. * I've set it to tomorrow so Module::CoreList won't be upset.
* Bump perl version in various places for 5.34.0Sawyer X2021-05-041-1/+1
|
* win32: remove makefile.mk (#18511)xenu2021-01-281-43/+17
| | | | | | | | | Makefile.mk is redundant with GNUmakefile. See https://www.nntp.perl.org/group/perl.perl5.porters/2021/01/msg258848.html for more details. We planned to remove it shortly after the introduction of GNUmakefile but that slipped through the cracks for some reason: https://github.com/Perl/perl5/issues/14341
* Restore build with some mingw.org compilers using mingw runtimes >= 3.21Steve Hay2021-01-261-5/+3
| | | | | | | | | | | | | | | | | | | | | | | MinGW runtime version 3.21 added a definition of mkstemp(), so requires a fix similar to f33b2f5852 for MinGW-w64's runtime 4.0 onwards. Based on a patch by Dan Collins on GH#15446. This commit also tweaks 43b3b04375, having discovered that mingw runtime 3.22 also contains a definition of timespec. For me, this fixes the build with my mingw.org 5.3.0 compiler using any of the mingw runtimes 3.21, 3.22.4 or 5.0 without breaking older versions such as 4.9.3 with the 3.20 runtime (or even with the withdrawn 4.0.3 runtime, which had __MINGW32_MAJOR/MINOR_VERSION set to 3.20 whilst adding new a __MINGW_MAJOR/MINOR_VERSION set to 4.0). However, 6.3.0 and 7.3.0 have other issues when compiling win32sck.c, while 8.2.0 and 9.2.0 have other issues again when compiling win32.c. See GH#18510 for more details. Also, C++ mode builds with some MinGW/MinGW-w64 compilers are still broken, as documented in 8a217c9aa7. See GH#16459 for more details.
* Fix typosSamanta Navarro2020-10-031-2/+2
| | | | | | | | | For: https://github.com/Perl/perl5/pull/18201 Committer: Samanta Navarro is now a Perl author. To keep 'make test_porting' happy: Increment $VERSION in several files. Regenerate uconfig.h via './perl -Ilib regen/uconfig_h.pl'.
* Bump to 5.33.0Sawyer X2020-06-281-1/+1
|
* Bump perl version in various places for 5.32.0Sawyer X2020-05-291-1/+1
|
* Fix a bunch of repeated-word typosDagfinn Ilmari Mannsåker2020-05-221-1/+1
| | | | | Mostly in comments and docs, but some in diagnostic messages and one case of 'or die die'.
* Bump back to 5.31.11, if we need to release itSawyer X2020-04-091-1/+1
|
* Bump version to 5.32.0Sawyer X2020-03-211-1/+1
|
* Fix language referring to GitHub issue tracker in various placesDave Rolsky2020-03-141-2/+2
| | | | | | | | | | | | There were a number of spots that used language more appropriate for an email address than a web-based tracker. I noticed this because of the recent 5.30.2 release, which has a perldelta containing the sentence "If you find any we have missed, send email to https://github.com/Perl/perl5/issues." But I think that was because the 5.30.2 branch did not include 8166b4e0bc220e759aa233af54ac1e60cc510f0c.
* Change various search.cpan.org references to metacpan.org and www.cpan.orgDan Book2020-01-221-1/+1
|
* Update documentation, readmes, comments, and utilities to reference the ↵Dan Book2019-12-221-7/+6
| | | | | | GitHub issue tracker The perlbug utility and perlbug@perl.org should no longer be used to submit bug reports or patches.
* The VC6 Chainsaw MassacreSteve Hay2019-10-171-13/+7
| | | | | Remove MS Visual C++ 6.0 support as agreed in the thread starting here: https://www.nntp.perl.org/group/perl.perl5.porters/2019/07/msg255625.html
* Change Microsoft URLs to their current locationMax Maischein2019-10-111-2/+2
|
* Move more URLs from http:// to https://Max Maischein2019-10-111-8/+8
|
* Bump the perl version in various places for 5.31.0Sawyer X2019-05-221-1/+1
|
* Bump the perl version in various places for 5.30.0Sawyer X2019-05-101-1/+1
|
* Update note of the test failures reportied in perl #133981Steve Hay2019-04-301-3/+4
|
* Make note of the test failures reportied in perl #133981Steve Hay2019-04-191-1/+5
|
* Add support for VS2019 (Visual C++ 14.2)Steve Hay2019-04-091-7/+7
| | | | | | This also fixes LINK_FLAGS for VS2017 (Visual C++ 14.1): The subsystem setting was missed in the changes to add VS2017 support, which was surely just an oversight.
* (perl #133462) add specific test run instructions to README.win32Tony Cook2019-02-051-0/+7
| | | | | | | | | | | README.win32 provides generally standalone instructions for running and testing perl, but unlike INSTALL didn't provide instructions for repeating individual tests. Both perlguts and INSTALL provide instructions on repeating individual tests, and considering at the point a user want this information they don't have a working perl installation, I think it's reasonable to repeat it here.
* fix typosAlexandr Savca2018-10-091-2/+2
| | | | | | | | Committer: For porting tests: Update $VERSION in 4 files. Run: ./perl -Ilib regen/mk_invlists.pl ./perl -Ilib regen/regcharclass.pl
* mention gmake builds in a few more places.Tony Cook2018-10-051-15/+19
|
* (perl #133494) better document CCHOME for GCC buildsTony Cook2018-10-051-1/+3
|
* Bump version to 5.29.0 and regenerate everythingSawyer X2018-06-241-1/+1
|
* Excessively long line made t/porting/podcheck.t unhappy.James E Keenan2018-05-241-1/+2
|
* Update information on which gcc versions are supported on WindowsSteve Hay2018-05-241-5/+12
| | | | | | See [perl #128631] (MinGW with runtimes >= 3.21 currently don't work) and [perl #132955] (MinGW 3.4.5 and 4.7.2+ and MinGW64 x64 6.3.0+ currently don't work in C++ mode).
* Fix Module::CoreList versionsSawyer X2018-04-201-1/+1
|
* Remove unnecessary MSVC*FREE CCTYPEs from Windows makefilesSteve Hay2017-06-161-2/+2
| | | | | | | As was pointed out recently in perl #131487, there is little point in most of these since the Express (now Community) versions are so close to the full versions anyway these days. MSVC70FREE is retained since it was the only one that was actually being made use of.
* We now support building with Visual Studio 2017 (VC++ 14.1)Steve Hay2017-06-161-9/+10
| | | | | (Support was added by commits 58998b2a91, 82cad14406, 74102a88af and 88b1365899.)
* Bump version: 5.26.0 -> 5.27.0, including fixesSawyer X2017-05-311-1/+1
|
* Bump version: 5.25.12 -> 5.26.0Sawyer X2017-04-211-1/+1
|
* Version debump: 5.26.0 -> 5.25.12Sawyer X2017-04-191-1/+1
|
* Version bump: 5.25.11 -> 5.26.0Sawyer X2017-03-201-1/+1
|
* Add support for VS2015 (VC++ 14.0)Steve Hay2017-02-191-9/+9
| | | | | | | | | | | | | | | Due to the rewritten CRT in this version of Visual C++ it is no longer possible (or at least not at all easy) to make use of the ioinfo struct, which commit b47a847f62 (re-)introduced in order to fix RT#120091/118059. Therefore, we effectively revert commit b47a847f62 for VS2015 onwards on the basis that being able to build with VS2015 onwards is more important than the RT#120091/118059 bug fix. This does unfortunately mean that perls built with <=VS2013 will not be compatible with perls built with >=VS2015, but they may well not have been compatible anyway because of the CRT rewrite, and certainly wouldn't be compatible if perl builds with VS2015 were not supported! See RT#125714 for more discussion about this.
* README*: remove deprecated L<"section"> and L<section> syntaxLukas Mai2016-06-111-3/+3
|
* bump version to v5.25.0Ricardo Signes2016-05-081-1/+1
|
* version bump: this is now v5.24.0-RC0!Ricardo Signes2016-04-101-1/+1
|
* add MSVC support to win32/GNUmakefileDaniel Dragan2016-01-251-8/+8
| | | | | | | | | | -copy things from makefile.mk to GNUmakefile -rework CFG_VARS to escape "s. Previously on gmake GCC builds, all "s inside the CFG_VARS vars were dropped from Config_heavy.pl due to command line parsing (dmake uses --cfgsh-option-file and a temp file, nmake escapes). Due to gmake's very poor temp file handling, keep it as a cmd line and dont convert it to a temp file. What vars to escape was modeled on the nmake makefile.
* add parallelness to win32/GNUmakefileDaniel Dragan2016-01-251-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | -.UPDATEALL is dmake only, doesn't exist in gmake, create more targets instead GNUmakefile:1319: warning: overriding recipe for target '.UPDATEALL' GNUmakefile:1024: warning: ignoring old recipe for target '.UPDATEALL' -fix ok/nok targets on dmake and gmake -dont delete old mini config.h, the copy overwrites it, for dmake and gmake 1 less process to run this way -modify whitespace and comments between 2 makesfiles so there are less delta lines if the 2 are diffed, this aids in diagnostics -remove perlmainst.c/perlmain.c build products, just use runperl.c directly 1 less disk file to create and later clean and git status and 2 less nodes in the make graph to traverse, also better for C debugger, since "runperl.c" is around after a git clean of the source tree, and runperl.c is in every single callstack in perl. -remove copying mini config.h to CORE dir, pointless since (mini) config.h isn't an input to config_h.PL, remove the exit 1 from commit 137443ea0a from 5.003, rewriting config.h is not a reason to stop the build with a fatal error, vivify CORE dir or else sub copy() fails -deshell UNIDATAFILES/mktables, 1 less cmd.exe process and 1 less .bat file written to disk for gmake (dmake always uses cmd.exe ATM) -combining mini config.h AKA $(MINIDIR)\.exists shell append lines is for another commit -perlglob.exe is not installed, it doesn't need to be rebased, it is only needed for module building, removing the dep makes the dep graph simpler -rename PERLIMPLIB so the lib is built in its final location in CORE dir this removes an extra xcopy process run. Since perl dll's .a/.lib is not longer in the root of the source tree, change the 2 tests and ExtUtils::CBuilder::Platform::Windows to look at the uninstalled final location dir, not the root dir -fix typo 0.282224->0.280224 in dist/ExtUtils-CBuilder/Changes -for GCC PERLEXPLIB must be used, passing "perldll.def" on cmd line to g++ means all data globals with EXTCONST are exported (which have dllexport on their declaration) instead of just what is in perldll.def and globvar.sym, INTERN/EXTERN.h could be revised to fix that, but I am not doing that at this time. Also drop linking GCC perl523.dll from 3 processes to just 1 process like with VC builds. Removing 2nd run of dlltool fixes a race condition where libperl523.a was generated twice. This caused a race condition failure where linking a XS DLL failed because the GCC linker of the XS DLL saw a partially written libperl523.a. -Relocation was tested with $(LINK32) -v -mdll -o $@ -Wl,--disable-auto-image-base -Wl,--image-base -Wl,0x400000 $(BLINK_FLAGS) $(PERLDLL_OBJ) $(shell @type Extensions_static) $(LIBFILES) $(PERLEXPLIB) to g++ linker to force an address conflict and verified with VMMap (unrelocated perl523.dll has ~40KB private memory, relocated has ~240KB private memory on Win 7 32b), historically there are problems with dllexport and dlltool and relocation problems with mingw -$(COREDIR)\ppport.h in gmake is separate lines since gmake normally launches processes directly, not through the shell, so it is more efficent to keep it as multiple lines for gmake, while dmake likes to burn CPU and IO between each line, and runs each line through cmd.exe -disable parallel building in make_ext.pl by not passing MAKEFLAGS env var to any subprocess, EUMM is not ready for parallelness inside a module building on Win32 -have harness proc and child .t procs share same disk perl.exe and perl523.dll files, this way they share memory pages, makefile.mk does the same thing
* fix more file pathsLukas Mai2016-01-101-1/+1
|
* add Win32 USE_NO_REGISTRY build optionDaniel Dragan2015-10-121-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | -the first arg of win32_get_privlib is not used if the registry is not queried, create a macro to allow the arg to drop out on WIN32_NO_REGISTRY builds for efficiency and not to have unused C litteral strings in the binary -This patch changes the ABI of PerlEnv_lib_path/PerlEnvLibPath/win32_get_privlib between USE_NO_REGISTRY and no USE_NO_REGISTRY. Since win32_get_privlib is not exported from perl523.dll, assume it and PerlEnv_lib_path are not public API, note technically PerlEnv_lib_path will be callable only on PERL_IMPLICIT_SYS builds, on no PERL_IMPLICIT_SYS builds it will fail at link time since win32_get_privlib isnt exported. Therefore place it in non-[affecting]-binary compatibility even though it does affect binary compatibility. -delay load advapi32.dll to save startup time (loading the DLL and the DLL calling its initializers in DllMain) and one 4 KB memory page for advapi32's .data section (doing "perl -E"sleep 100" on WinXP shows advapi32 has a 20KB long .data section, first 4 KB are unique to the process, the remaining 16KB are COW shared between processes according to vmmap tool), putting a DebugBreak() in pp_getlogin and doing a "nmake all" shows miniperl never calls getlogin during the build process. An nmake test shows only ext/POSIX/t/wrappers.t and lib/warnings.t execute pp_getlogin. Keeping advapi32.dll out of the perl process requires removing comctl32.dll, since comctrl32.dll loads advapi32.dll, from perl which I always do as a custom patch. filed as [perl #123658] XXXXXXXXXXXXXXXXXXXXXXX
* stop checking the Win32 registry if *"/Software/Perl" doesn't existDaniel Dragan2015-10-121-4/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This stops each ENV var lookup (and 16 calls to get_regstr, most of which are %ENV lookups, are done automatically each time a Win32 Perl process starts) from querying the registry for usually failing lookups. ActiveState is the only known major user of the Software/Perl reg key. details: -cache the root handles, so a typically failing env var lookup does only 1 system call instead of 3 if the parent key exists -if the key exists, looking it up is slightly faster since it is 4 registry syscall instead of previously 6 (open "*\Software\Perl", 2 RegQueryValueExAs(on "found" behavior each RegQueryValueExA does 2 RegQueryValueExW calls), close "*\Software\Perl") -dont make a system call to lookup a value if the parent key doesn't exist -change "Software\\Perl" to "SOFTWARE\\Perl" since the reg is case preserving but lookups are not case sensitive, this all caps casing is what regedit shows, and might save a couple cpu cycles in the DB lookup in the kernel -use RegOpenKeyExW instead of RegOpenKeyEx (actually RegOpenKeyExA), this avoids ansi to utf16 conversions at runtime -dont check HKEY handles for NULL before calling RegCloseKey. MS and ReactOS RegCloseKey checks for NULL (zero) handle first thing and returns ERROR_INVALID_HANDLE as the retval of RegCloseKey. MS App Verifier does not complain about NULL handles. -Dont check the retval of RegCloseKey, there is no way to dispatch an error at this point in the process, there are no interps, and no perlio, and maybe no console if its a GUI, and the process is probably exiting anyway. Calling Perl_noperl_die (no perl, no perlio, print to stderr) would not be friendly to an embedder. A crash box with RaiseException with EXCEPTION_INVALID_HANDLE is a bad UI. -Dont bother to zero the HKEY handles, after a PERL_SYS_TERM until the next (if any) PERL_SYS_INIT3, libperl is in an undefined state, it is the embedders responsibility to refcount and serialize calls to PERL_SYS_INIT3/PERL_SYS_TERM if necessary See details in [perl #123658]
View Lorry Controller Status