[PATCH] Move Win32 from win32/ext/Win32 to ext/Win32To compile the Win32 module under both "MSWin32" and "cygwin" the module
needs to be moved to the ext/ subdirectory. To preserve the change history
this should be done with `p4 integrate`:
p4 integrate win32/ext/Win32/... ext/Win32/...
p4 delete win32/ext/Win32/...
The attached patch then updates Configure to build the module under cygwin
only, and updates the MANIFEST. The MSWin32 builds will continue to find
the module automatically using the FindExt.pm module.
Cheers,
-Jan
diff -dur bleadperl/Configure bleadnew/Configure
--- bleadperl/Conf...
[PATCH] RE: PeekMessage() call in win32\win32.c win32_async_check------=_NextPart_000_015A_01C601C4.9DB30210
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: 7bit
On Tue, 13 Dec 2005, Jan Dubois wrote:
> On Sat, 10 Dec 2005, Jan Dubois wrote:
>> On Sat, 10 Dec 2005, Nick Ing-Simmons wrote:
>>> Found this festering in an archive mailbox seems related to recent
>>> "alarm() ..." thread
I've addressed the issues raised in that message as good as possible
for WinNT and earlier. For Windows 2000 and later they should be
fixed completely due to using our own message window ...
[PATCH] get ext/Win32/Win32.xs to compile on cygwin----=_l7irn21hmijqdimi9l14v652q69nqrhgio.MFSBCHJLHS
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
The functions from win32/win32.c don't compile out-of-the-box on
cygwin. The attached patch fixes this, mostly along the lines of
the externally maintained win32core module for cygwin:
http://libwin32-exp.cvs.sourceforge.net/libwin32-exp/libwin32-exp/Win32CORE/
I'm not too happy about 2 issues though:
1) The win32_longpath() function is duplicated in Win32.xs for cygwin.
We can call the version in win32/win32.c for MSWin32, but that
o...
[patch] ext/Win32/Win32.xs compilation fails on msvc < 6A patch for smoke, fixes compilation on older msvc versions:
--- /home/dk/src/perl-current/ext/Win32/Win32.xs 2007-06-26 11:10:49.000000000 +0200
+++ ./Win32.xs 2007-09-17 10:49:43.000000000 +0200
@@ -43,6 +43,13 @@
# define CSIDL_FLAG_CREATE 0x8000
#endif
+#ifndef CSIDL_COMMON_FAVORITES
+# define CSIDL_COMMON_FAVORITES 0x001F
+# define CSIDL_COOKIES 0x0021
+# define CSIDL_HISTORY 0x0022
+# define CSIDL_INTERNET_CACHE 0x0020
+#endif
+
#ifndef CSIDL_ADMINTOOLS
# define CSIDL_ADMINTOOLS 0x0030
...
[PATCH win32/win32.c] silence compiler warnings--------------Boundary-00=_6UC8EV15X4AEVLIULI8W
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Hi porters,
These warnings should be gone with this patch:
win32.c: In function `win32_execvp':
win32.c:3974: warning: passing arg 3 of `win32_spawnvp' from incompatible=
pointer type
win32.c: In function `w32_DomainName':
win32.c:4433: warning: passing arg 2 of `WideCharToMultiByte' makes integ=
er from pointer without a cast
win32.c:4437: warning: passing arg 2 of `WideCharToMultiByte' makes integ=
er from...
Win32::API and Win32::GUIHello,
Is there anyone using one of these modules?
I would like to exchange information about
how to use them.
Thanks in Advance,
H3li0
__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - buy the things you want at great prices
http://auctions.yahoo.com/
On Sun, May 27, 2001 at 11:32:16PM -0700, Helio S. Junior wrote:
> Is there anyone using one of these modules?
> I would like to exchange information about
> how to use them.
You're likely to find people using those modules on
<perl-win32-users@activestate.com&g...
Re: Include the Win32 extension in the ALL_STATIC build on Win32On Fri, Jun 7, 2013 at 3:48 PM, Steve Hay <steve.m.hay@googlemail.com> wrote:
> The last-but-one thing to do is to arrange for init_Win32CORE to be
> exported from perl-static.exe (as it already is from perl519.dll, courtesy
> of makedef.pl) otherwise GetProcAddress() won't find it. I see no harm in
> always specifying __declspec(dllexport) in Win32CORE.c (except in one
> existing Cygwin case which doesn't want it, which I'm not touching to
> minimize regression risk). I thought that the .def file entry written by
> make...
[PATCH] README.win32 and win32/makefile.mk differHi!
README.win32 says:
> ... The
> defaults in the dmake makefile are setup to build using the GCC
> compiler.
But win32/makefile.mk contains:
#CCTYPE *= MSVC20
#CCTYPE *= MSVC
CCTYPE *= MSVC60
#CCTYPE *= BORLAND
#CCTYPE *= GCC
This patch makes README.win32 follow win32/makefile.mk:
--- README.win32.orig Wed Jun 5 04:02:02 2002
+++ README.win32 Fri Jun 7 13:21:40 2002
@@ -192,7 +192,8 @@
This directory contains a "Makefile" that will work with
versions of nmake that come with Visual C++ or the Platform SDK, and
a dmake "makefile.mk&...
[PATCH t\win32] system_tests are relevant only to win32\system.tsystem_tests are relevant only to win32\system.t, so let them be in the
same directory. This patch does that.
After applying this, someone should move t\op\system_tests to
t\win32\system_tests.
[Patch]
diff -uaNdr bleadperl/t/win32/system.t workin_bleadperl/t/win32/system.t
--- bleadperl/t/win32/system.t Wed Apr 24 02:15:06 2002
+++ workin_bleadperl/t/win32/system.t Fri Apr 26 15:23:32 2002
@@ -96,7 +96,7 @@
END {
chdir($cwd) && rmtree("$cwd/$testdir") if -d "$cwd/$testdir";
}
-if (open(my $EIN, "$cwd/op/${exename}_exe.uu")) {
...
Difference between Win32::API and Win32::OLE.Difference between Win32::API and Win32::OLE.
As I know, Win32::API can import and call functions from Win32's
Dynamic Link Libraries (DLL),
I was wondering if it can import and call functions from standalone
executables, just like Win32:OLE does.
I tried Win32::OLE to call serveral funtions in a satandalone executbles,
but failed with an error: Type Mismatch...
I cannot find a good way to avoid this error...
...
[PATCH 5.6.0+] fix for Win32::GetFullPathName and Win32::GetShortPathNameOn Win NT 4, the GetShortPathName() and GetFullPathName() APIs crash when
invoked with an empty filename. Attached patch avoids this. Of course it
doesn't make any sense to call these functions without a filename, but
that is a different issue.
-Jan
--- win32/win32.c.prev Fri Jul 14 19:33:26 2000
+++ win32/win32.c Fri Aug 18 16:22:54 2000
@@ -3860,6 +3860,9 @@
shortpath = sv_mortalcopy(ST(0));
SvUPGRADE(shortpath, SVt_PV);
+ if (!SvPVX(shortpath) || !SvLEN(shortpath))
+ XSRETURN_UNDEF;
+
/* src == target is allowed */
do {
len = Get...
de-forking cygwin and win32 code for Win32::*For some time now, the cygwin perl binary release has included a
staticly built module Win32CORE that has the "CORE" Win32:: routines
from win32/win32.c, suitably modified to run under cygwin.
The cygwin release also does not include the dynamically loadable
Win32 module which was added to the perl core for regular win32
builds only, under the win32/ext/Win32 directory. Instead it is
available as part of the libwin32 distribution.
Unfortunately, in both cases there has been some drift; there have
been changes made to win32.c that are not in the cygwin Win32CORE
patch, a...
win32sI have just one general question:
Does Power++ 2 generate WIN32s code (what version)?
Thanks for answer.
Dalibor
*********************************************************************
Dalibor Zliechovec telephone: +420 7 761604,787798
Frequentis, spol. s r. o. company WWW: www.frequentis.com
Hanulova 5/B company e-mail: frqbra@computel.sk
841 01 Bratislava private e-mail:zliecho@pdpr.pod.sk
Dalibor Zliechovec wrote:
> I have just one general question:
> Does Power++ 2 generate WIN32s code (what version)?
...
POE::Wheel::Run::Win32 and Win32::Daemon--------------enig6560CC5F54D4E6ED522748F5
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Hi,
this will be especially interesting for dolman :-)
as already described in previous emails there is a big problem when
using POE::Wheel::Run::Win32 with Win32::Daemon as a windows service.
Your service will get a termination request from windows, as soon as any
child process terminates.
This happens because POE::Wheel::Run::Win32 is using the fork() method.
I do not know how exactly ActiveStates Perl handles the fork() method,
but it does i...