[prev in list] [next in list] [prev in thread] [next in thread]
List: mingw-notify
Subject: MinGW-notify digest, Vol 1 #723 - 9 msgs
From: mingw-notify-request () lists ! sourceforge ! net
Date: 2004-02-15 6:10:02
Message-ID: 200402150608.i1F68KU2026279 () mailer ! progressive-comp ! com
[Download RAW message or body]
Send MinGW-notify mailing list submissions to
mingw-notify@lists.sourceforge.net
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.sourceforge.net/lists/listinfo/mingw-notify
or, via email, send a message with subject or body 'help' to
mingw-notify-request@lists.sourceforge.net
You can reach the person managing the list at
mingw-notify-admin@lists.sourceforge.net
When replying, please edit your Subject line so it is more specific
than "Re: Contents of MinGW-notify digest..."
This list is used to send updates of submitted patches, bug reports and file \
releases. You are discouraged from posting to this list. If you wish to unsubscribe \
you can do so at https://lists.sourceforge.net/lists/listinfo/mingw-notify.
Today's Topics:
1. [ mingw-Bugs-786031 ] A proposed htmlhelp.h (SourceForge.net)
2. [ mingw-Bugs-646577 ] dlltool --as broken on Me: can't exec as \
(SourceForge.net) 3. [ mingw-Bugs-786031 ] A proposed htmlhelp.h (SourceForge.net)
4. [ mingw-Bugs-735197 ] Installation issue (SourceForge.net)
5. [ mingw-Bugs-726289 ] make thinks 12:48am is later than 10:00am \
(SourceForge.net) 6. [ mingw-Bugs-739778 ] ld cause internal error. \
(SourceForge.net) 7. [ mingw-Bugs-733982 ] Missing win32api functionality \
(SourceForge.net) 8. [ mingw-Bugs-733982 ] Missing win32api functionality \
(SourceForge.net) 9. [ mingw-Bugs-751228 ] Missing Win32 functionality - Raw Input \
(SourceForge.net)
--__--__--
Message: 1
To: noreply@sourceforge.net
From: "SourceForge.net" <noreply@sourceforge.net>
Date: Fri, 13 Feb 2004 23:41:08 -0800
Subject: [Mingw-notify] [ mingw-Bugs-786031 ] A proposed htmlhelp.h
Bugs item #786031, was opened at 2003-08-10 08:28
Message generated for change (Comment added) made by dannysmith
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=786031&group_id=2435
Category: w32api
Group: Feature requests
Status: Open
Resolution: None
Priority: 5
Submitted By: Phil Krylov (likewolf)
Assigned to: Danny Smith (dannysmith)
Summary: A proposed htmlhelp.h
Initial Comment:
This is an initial version of htmlhelp.h attached.
----------------------------------------------------------------------
> Comment By: Danny Smith (dannysmith)
Date: 2004-02-14 20:41
Message:
Logged In: YES
user_id=11494
AFAICT, htmlhelp.lib (the lib that contains the definitions of
the functions in htmlhlp.h) is only available as a static lib
distributed by MS. The MS htmlhelp SDK package contains
the header, of course, as well as the lib.
Why are we bothering with this header if we can't provide a
way to resolve the symbols decalred in it.
Danny
----------------------------------------------------------------------
Comment By: Earnie Boyd (earnie)
Date: 2004-02-14 07:16
Message:
Logged In: YES
user_id=15438
Danny,
Should we add this? I assigned it to you since you
responded to likewolf. He uploaded a new file after your
comment.
Earnie
----------------------------------------------------------------------
Comment By: Phil Krylov (likewolf)
Date: 2003-08-10 19:27
Message:
Logged In: YES
user_id=86146
Attached corrected version.
----------------------------------------------------------------------
Comment By: Danny Smith (dannysmith)
Date: 2003-08-10 16:28
Message:
Logged In: YES
user_id=11494
The prototype is wrong. This is what I find in MSDN docs:
http://msdn.microsoft.com/library/default.asp?url=/library/en-
us/htmlhelp/html/vsconovabouthtmlhelpcommands.asp
HWND HtmlHelpA(
HWND hwndCaller,
LPCSTR pszFile,
UINT uCommand,
DWORD dwData) ;
Danny
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=786031&group_id=2435
--__--__--
Message: 2
To: noreply@sourceforge.net
From: "SourceForge.net" <noreply@sourceforge.net>
Date: Sat, 14 Feb 2004 20:43:44 -0800
Subject: [Mingw-notify] [ mingw-Bugs-646577 ] dlltool --as broken on Me: can't exec \
as
Bugs item #646577, was opened at 2002-12-01 14:36
Message generated for change (Settings changed) made by earnie
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=646577&group_id=2435
Category: binutils
Group: component package
> Status: Closed
> Resolution: Fixed
Priority: 9
Submitted By: Kevin Kofler (kevinkofler)
Assigned to: Nobody/Anonymous (nobody)
Summary: dlltool --as broken on Me: can't exec as
Initial Comment:
The --as option of dlltool.exe in the binutils-2.13.90-
20021006-2 release does not seem to work correctly
on Windows Me. I get the following error:
e:\mingw32\bin\dlltool.exe: installation problem,
cannot exec `E:/MINGW32/BIN/AS.EXE'
and I get an error of that form no matter what I pass
as --as, even when I just pass "--as=as" or "--
as=as.exe".
This is a problem because libtool always passes an --
as switch to dlltool. I can just change the parameter
by setting $AS, but I cannot remove the --as switch
without hand-editing autogenerated files like configure
or libtool.
I guess E:\MINGW32\BIN\AS.EXE would work, but
something (MSYS? dlltool itself?) always seems to
translate it to E:/MINGW32/BIN/AS.EXE, which
doesn't work.
----------------------------------------------------------------------
Comment By: Paul Garceau (pgarceau)
Date: 2004-02-14 02:38
Message:
Logged In: YES
user_id=1762
Checked under Win98 (plain vanilla Mingw) using latest
binutils. Problem is gone.
output now:
D:\mingw>dlltool -v
D:\MINGW\BIN\DLLTOOL.EXE: Using file: D:\MINGW\BIN\as
D:\MINGW\BIN\DLLTOOL.EXE: Processing definitions
D:\MINGW\BIN\DLLTOOL.EXE: Processed definitions
----------------------------------------------------------------------
Comment By: Danny Smith (dannysmith)
Date: 2004-02-13 21:28
Message:
Logged In: YES
user_id=11494
This should have been fixed by libiberty changes. Can some
one test on w9x with recent binutils.
2003-07-02 Danny Smith
<dannysmith@users.sourceforge.net>
* pex-win32.c (fix_argv): Ensure that the
executable pathname
uses Win32 backslashes.
----------------------------------------------------------------------
Comment By: Earnie Boyd (earnie)
Date: 2004-02-13 19:41
Message:
Logged In: YES
user_id=15438
I don't think this has been resolved. The fix will need to
be resolved in dlltool to insure that the exec'ed process
contains \ instead of /.
Earnie.
----------------------------------------------------------------------
Comment By: Earnie Boyd (earnie)
Date: 2003-02-19 07:20
Message:
Logged In: YES
user_id=15438
mingw-Bugs-689160 is being tracked here.
----------------------------------------------------------------------
Comment By: Paul Garceau (pgarceau)
Date: 2003-02-18 19:14
Message:
Logged In: YES
user_id=1762
A similar pathing error occurs using dllwrap.exe for Win9x/Me.
In this case, however, it is caused when dllwrap.exe
attempts to run g++.exe.
Details:
g++ -v
Reading specs from
d:/msys/1.0/mingw/bin/../lib/gcc-lib/mingw32/3.2.2/specs
Configured with: ../gcc/configure --with-gcc --with-gnu-ld
--with-gnu-as --host=mingw32 --target=mingw32
--prefix=/mingw --enable-threads --disable-nls
--enable-languages=c++,f77,objc --disable-win32-registry
--disable-shared --enable-sjlj-exceptions
Thread model: win32
gcc version 3.2.2 (mingw special 20030208-1)
dllwrap -vers
GNU d:\msys\1.0\mingw\bin\dllwrap.exe 2.13
sh --version
GNU bash, version 2.04.0(1)-release (i686-pc-msys)
OS: Win98
Error:
dllwrap --driver-name=g++ ... -q --def= foo_out.def
--no-export-all-symbols --dllname foo.dll
yields:
d:\msys\1.0\mingw\bin\dllwrap.exe: installation problem,
cannot exec `g++': No such file or directory
----------------------------------------------------------------------
Comment By: Luke Dunstan (infidel)
Date: 2003-01-05 00:59
Message:
Logged In: YES
user_id=30442
Yes, Kevin was right originally when he said that MSYS
translates the PATH variable to forward slashes. I can
reproduce this error on Win98 but apparently it works fine
on Win2K, which is not surprising.
----------------------------------------------------------------------
Comment By: Kevin Kofler (kevinkofler)
Date: 2003-01-05 00:39
Message:
Logged In: YES
user_id=573515
> Kevin, is this still a problem with MSYS-1.0.8.exe?
Unfortunately, it is. :-(
I have installed the production MSYS-1.0.8.exe and I still
get (using --as=as):
e:\mingw32\bin\dlltool.exe: run: as -o .libs/libticables-
3.dll-exp dc.s
e:\mingw32\bin\dlltool.exe: No such file or directory
e:\mingw32\bin\dlltool.exe: installation problem, cannot
exec `as'
whereas running:
as -o .libs/libticables-3.dll-exp dc.s
directly from the (MSYS bash) command line works just
fine.
Just as before, using --as=as.exe, --as=/mingw/bin/as, --
as=/mingw/bin/as.exe, or even --as=E:\mingw32
\bin\as.exe does not work either, whereas omitting --as
entirely does work (but as I said, libtool won't let me do
that within the libtoolized build without patching auto-
generated files).
----------------------------------------------------------------------
Comment By: Earnie Boyd (earnie)
Date: 2003-01-04 22:17
Message:
Logged In: YES
user_id=15438
Are you Kevin, the OP? I think not. Your problem is that
your command line ``dlltool --as /mingw/bin/as.exe
--output-lib libd3d8.a --input-def d3d8.def --dllname
d3d8.dll -k'' uses /mingw/bin/as.exe as a path argument to
the --as switch and you're not using the MSYS shell.
Earnie.
----------------------------------------------------------------------
Comment By: Rupesh Srivastava (uhap078)
Date: 2003-01-04 15:04
Message:
Logged In: YES
user_id=663829
hi - I still don't know where the problem is - which is frustrating - but I've got a
workaround to my specific problem of tying to run reimp. As I mentioned
before, I can generate .a files manually. So I've knocked up a C++ app
which does the following:
- search current directory for libs
-
generate batch file with the necessary params for reimp and dlltool
-
execute batch file and remove it afterwards
It's not that elegant - but it
works.
----------------------------------------------------------------------
Comment By: Earnie Boyd (earnie)
Date: 2003-01-04 12:26
Message:
Logged In: YES
user_id=15438
Kevin, is this still a problem with MSYS-1.0.8.exe?
Earnie.
----------------------------------------------------------------------
Comment By: Rupesh Srivastava (uhap078)
Date: 2002-12-06 16:30
Message:
Logged In: YES
user_id=663829
hi everyone.
I stumbled across this post - as I'm having similar
problems - but on XP Pro.
I'm running MinGW and downloaded the
utils so that I could run reimp on some directx 8 libs. The def files get
generated but the error "Invalid argument" occurs for dlltool. On closer
inspection, I got the following error msg: dlltool: installation problem,
cannot exec `as'.
So I tried the following for the d3d8.lib file
(manually): dlltool --as /mingw/bin/as.exe --output-lib libd3d8.a --input-def
d3d8.def --dllname d3d8.dll -k
and that works fine :-) However the
reimp stuff still bombs (after generating the def file) - but I guess I'll
eventually get to the bottom of it.
----------------------------------------------------------------------
Comment By: Danny Smith (dannysmith)
Date: 2002-12-02 14:52
Message:
Logged In: YES
user_id=11494
My experience:
Passing forward-slashed commandline args to
W95,W98,or WinME versions of CreateProcess (or any of
the spawn CRT functions that wrapt CreateProcess)
cause problems _iff_ the command-line arg is quoted.
Now libiberty;s pexecute which dlltool (and many other
GCC tools) uses to run commands takes great pain to
ensure that the args are quoted to sort out problems
with embedded blanks in filenames. You can't win.
This is not problem on NT lineage of CreateProcess
Danny
----------------------------------------------------------------------
Comment By: Kevin Kofler (kevinkofler)
Date: 2002-12-02 06:53
Message:
Logged In: YES
user_id=573515
And I can confirm my supposition:
running "/c/command.com //c set"
or "/c/command.com //c echo %PATH%" from MSYS
shows that the inherited PATH uses forward slashes as
path separators.
----------------------------------------------------------------------
Comment By: Kevin Kofler (kevinkofler)
Date: 2002-12-02 06:47
Message:
Logged In: YES
user_id=573515
It is, but the path gets translated to POSIX and back to
Win32 by MSYS as well, so it probably has the same
problem.
----------------------------------------------------------------------
Comment By: Luke Dunstan (infidel)
Date: 2002-12-02 06:22
Message:
Logged In: YES
user_id=30442
If you pass --as=/mingw/bin/as.exe, MSYS would translate it
to --as=e:/mingw32/bin/as.exe, but I wasn't aware that the
forward slashes would be a problem on WinME. However,
MSYS will not translate --as=as or --as=as.exe, so there is
probably another problem. Is as.exe in your PATH?
----------------------------------------------------------------------
Comment By: Kevin Kofler (kevinkofler)
Date: 2002-12-01 18:39
Message:
Logged In: YES
user_id=573515
I should add that I am currently using MSYS 1.08-rc4.
What's strange is that "dlltool --as=as" or "dlltool --
as=as.exe" does not work either, whereas omitting --as
works.
The output from "dlltool -v --as=as.exe ..." is:
...
e:\mingw32\bin\dlltool.exe: run: as.exe -
o .libs/libticables-3.dll-exp dc.s
e:\mingw32\bin\dlltool.exe: No such file or directory
e:\mingw32\bin\dlltool.exe: installation problem, cannot
exec `as.exe'
The output from "dlltool -v --as=as ..." is:
...
e:\mingw32\bin\dlltool.exe: run: as -o .libs/libticables-
3.dll-exp dc.s
e:\mingw32\bin\dlltool.exe: No such file or directory
e:\mingw32\bin\dlltool.exe: installation problem, cannot
exec `as'
When I omit --as, I get:
...
e:\mingw32\bin\dlltool.exe: run: e:\mingw32\bin\as -
o .libs/libticables-3.dll-exp dc.s
e:\mingw32\bin\dlltool.exe: Generated exports file
----------------------------------------------------------------------
Comment By: Danny Smith (dannysmith)
Date: 2002-12-01 18:28
Message:
Logged In: YES
user_id=11494
AFAICT, dlltool use the name of as exactly as entered on
the command line. I cannot reproduce the error when
running dlltool from a DOS box on W98.
Earnie, is this a msys bug?
Danny
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=646577&group_id=2435
--__--__--
Message: 3
To: noreply@sourceforge.net
From: "SourceForge.net" <noreply@sourceforge.net>
Date: Sat, 14 Feb 2004 20:46:35 -0800
Subject: [Mingw-notify] [ mingw-Bugs-786031 ] A proposed htmlhelp.h
Bugs item #786031, was opened at 2003-08-09 16:28
Message generated for change (Comment added) made by earnie
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=786031&group_id=2435
Category: w32api
Group: Feature requests
> Status: Closed
> Resolution: Rejected
Priority: 5
Submitted By: Phil Krylov (likewolf)
Assigned to: Danny Smith (dannysmith)
Summary: A proposed htmlhelp.h
Initial Comment:
This is an initial version of htmlhelp.h attached.
----------------------------------------------------------------------
> Comment By: Earnie Boyd (earnie)
Date: 2004-02-14 23:46
Message:
Logged In: YES
user_id=15438
Ok. Sounds reasonable to me. I'm closing this ticket as
rejected for the reasons Danny states.
----------------------------------------------------------------------
Comment By: Danny Smith (dannysmith)
Date: 2004-02-14 02:41
Message:
Logged In: YES
user_id=11494
AFAICT, htmlhelp.lib (the lib that contains the definitions of
the functions in htmlhlp.h) is only available as a static lib
distributed by MS. The MS htmlhelp SDK package contains
the header, of course, as well as the lib.
Why are we bothering with this header if we can't provide a
way to resolve the symbols decalred in it.
Danny
----------------------------------------------------------------------
Comment By: Earnie Boyd (earnie)
Date: 2004-02-13 13:16
Message:
Logged In: YES
user_id=15438
Danny,
Should we add this? I assigned it to you since you
responded to likewolf. He uploaded a new file after your
comment.
Earnie
----------------------------------------------------------------------
Comment By: Phil Krylov (likewolf)
Date: 2003-08-10 03:27
Message:
Logged In: YES
user_id=86146
Attached corrected version.
----------------------------------------------------------------------
Comment By: Danny Smith (dannysmith)
Date: 2003-08-10 00:28
Message:
Logged In: YES
user_id=11494
The prototype is wrong. This is what I find in MSDN docs:
http://msdn.microsoft.com/library/default.asp?url=/library/en-
us/htmlhelp/html/vsconovabouthtmlhelpcommands.asp
HWND HtmlHelpA(
HWND hwndCaller,
LPCSTR pszFile,
UINT uCommand,
DWORD dwData) ;
Danny
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=786031&group_id=2435
--__--__--
Message: 4
To: noreply@sourceforge.net
From: "SourceForge.net" <noreply@sourceforge.net>
Date: Sat, 14 Feb 2004 21:50:42 -0800
Subject: [Mingw-notify] [ mingw-Bugs-735197 ] Installation issue
Bugs item #735197, was opened at 2003-05-09 08:13
Message generated for change (Settings changed) made by earnie
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=735197&group_id=2435
Category: non-mingw
Group: None
Status: Open
> Resolution: Remind
> Priority: 1
Submitted By: Adrian Boeing (adrianboeing)
Assigned to: Nobody/Anonymous (nobody)
Summary: Installation issue
Initial Comment:
OS: WindowsXP
MinGW-2.0.0-3.exe
When installing to "C:\Program Files\MinGW" cc1plus.exe
can not be found. Uninstalling and reinstalling to "C:
\MinGW" fixes this. Guessing there is a bug with handling
directories with spaces in thier names in the installation
code?
Sorry about the lame bug report.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=735197&group_id=2435
--__--__--
Message: 5
To: noreply@sourceforge.net
From: "SourceForge.net" <noreply@sourceforge.net>
Date: Sat, 14 Feb 2004 21:51:42 -0800
Subject: [Mingw-notify] [ mingw-Bugs-726289 ] make thinks 12:48am is later than \
10:00am
Bugs item #726289, was opened at 2003-04-23 11:07
Message generated for change (Settings changed) made by earnie
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=726289&group_id=2435
Category: None
Group: None
> Status: Closed
> Resolution: Out of Date
Priority: 5
Submitted By: Charles Evans (cvevans)
Assigned to: Nobody/Anonymous (nobody)
Summary: make thinks 12:48am is later than 10:00am
Initial Comment:
make 3.79.1 said nothing to be done
nmake did the rule ok.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=726289&group_id=2435
--__--__--
Message: 6
To: noreply@sourceforge.net
From: "SourceForge.net" <noreply@sourceforge.net>
Date: Sat, 14 Feb 2004 21:52:46 -0800
Subject: [Mingw-notify] [ mingw-Bugs-739778 ] ld cause internal error.
Bugs item #739778, was opened at 2003-05-19 06:13
Message generated for change (Settings changed) made by earnie
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=739778&group_id=2435
Category: ld
Group: None
> Status: Closed
> Resolution: Invalid
Priority: 5
Submitted By: Sergiy Yakovyn (ysv_)
Assigned to: Danny Smith (dannysmith)
Summary: ld cause internal error.
Initial Comment:
I've got this message while compiling my project:
===================================
d:\mingw\bin\..\lib\gcc-lib\mingw32\3.2.3
\..\..\..\..\mingw32\bin\ld.exe: BFD 2.13 internal error,
aborting at ../../src/bfd/coffcode.h line 832 in
handle_COMDAT
d:\mingw\bin\..\lib\gcc-lib\mingw32\3.2.3
\..\..\..\..\mingw32\bin\ld.exe: Please report this bug.
d:\mingw\bin\mmake.EXE: *** [testRecorder.exe] Error 1
=========================================
I attach some files to help debug the problem.
Sergiy Yakovyn
----------------------------------------------------------------------
Comment By: Sergiy Yakovyn (ysv_)
Date: 2003-05-20 04:29
Message:
Logged In: YES
user_id=779069
Sorry, I can't send libcppunit.a - zipped - 890k. But after
rebooting the error disappear.
----------------------------------------------------------------------
Comment By: Danny Smith (dannysmith)
Date: 2003-05-19 17:16
Message:
Logged In: YES
user_id=11494
Unfortunately, I can't reproduve the bug unless I have
the missing libcppunit.a.
Was that lib compiled with G++ 3.0 or higher? If not, all
bets are off. Other compilers use different naming
convention for comdat symbols in object files than does
GCC. G++-2.9.x used different mangling for the actual
symbol name, thanm does 3.x . If it was complied and
assembled with GNU tools (GCC 3.x), than please
upload that library file as well.
Danny
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=739778&group_id=2435
--__--__--
Message: 7
To: noreply@sourceforge.net
From: "SourceForge.net" <noreply@sourceforge.net>
Date: Sat, 14 Feb 2004 22:00:09 -0800
Subject: [Mingw-notify] [ mingw-Bugs-733982 ] Missing win32api functionality
Bugs item #733982, was opened at 2003-05-07 12:36
Message generated for change (Comment added) made by earnie
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=733982&group_id=2435
Category: w32api
Group: Feature requests
Status: Open
Resolution: None
Priority: 5
Submitted By: Chris Sutcliffe (ir0nh34d)
> Assigned to: Danny Smith (dannysmith)
Summary: Missing win32api functionality
Initial Comment:
I've noticed a couple of things missing from the win32
api, which I have since added to my project by creating
a header with the relevant information (derived from a
google seach and msdn.microsoft.com). Namely:
CGID_ShellServiceObject
which I have as:
DEFINE_GUID(CGID_ShellServiceObject,
0x000214D2, 0x00, 0x00, 0xC0, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x46);
as well as:
SetLayeredWindowAttributes
which I have available via:
GetProcAddress(GetModuleHandle
("user32.dll"), "SetLayeredWindowAttributes");
Keep up the amazing work, and let me know if I can
help out.... Cheers!
Chris
----------------------------------------------------------------------
> Comment By: Earnie Boyd (earnie)
Date: 2004-02-15 01:00
Message:
Logged In: YES
user_id=15438
Danny,
Is the CGID_ShellServiceObject define above appropriate? I see
$ grep CGID_ShellServiceObject * -r
shlguid.h:extern const GUID CGID_ShellServiceObject;
defined already.
Earnie
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=733982&group_id=2435
--__--__--
Message: 8
To: noreply@sourceforge.net
From: "SourceForge.net" <noreply@sourceforge.net>
Date: Sat, 14 Feb 2004 22:00:43 -0800
Subject: [Mingw-notify] [ mingw-Bugs-733982 ] Missing win32api functionality
Bugs item #733982, was opened at 2003-05-07 12:36
Message generated for change (Settings changed) made by earnie
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=733982&group_id=2435
Category: w32api
Group: Feature requests
Status: Open
Resolution: None
> Priority: 9
Submitted By: Chris Sutcliffe (ir0nh34d)
Assigned to: Danny Smith (dannysmith)
Summary: Missing win32api functionality
Initial Comment:
I've noticed a couple of things missing from the win32
api, which I have since added to my project by creating
a header with the relevant information (derived from a
google seach and msdn.microsoft.com). Namely:
CGID_ShellServiceObject
which I have as:
DEFINE_GUID(CGID_ShellServiceObject,
0x000214D2, 0x00, 0x00, 0xC0, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x46);
as well as:
SetLayeredWindowAttributes
which I have available via:
GetProcAddress(GetModuleHandle
("user32.dll"), "SetLayeredWindowAttributes");
Keep up the amazing work, and let me know if I can
help out.... Cheers!
Chris
----------------------------------------------------------------------
Comment By: Earnie Boyd (earnie)
Date: 2004-02-15 01:00
Message:
Logged In: YES
user_id=15438
Danny,
Is the CGID_ShellServiceObject define above appropriate? I see
$ grep CGID_ShellServiceObject * -r
shlguid.h:extern const GUID CGID_ShellServiceObject;
defined already.
Earnie
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=733982&group_id=2435
--__--__--
Message: 9
To: noreply@sourceforge.net
From: "SourceForge.net" <noreply@sourceforge.net>
Date: Sat, 14 Feb 2004 22:06:03 -0800
Subject: [Mingw-notify] [ mingw-Bugs-751228 ] Missing Win32 functionality - Raw Input
Bugs item #751228, was opened at 2003-06-09 04:43
Message generated for change (Comment added) made by earnie
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=751228&group_id=2435
Category: w32api
Group: Known bugs
> Status: Closed
> Resolution: Fixed
Priority: 5
Submitted By: Enabler (enkanba)
Assigned to: Earnie Boyd (earnie)
Summary: Missing Win32 functionality - Raw Input
Initial Comment:
OS Version: Windows 2000
gcc version: 2.95.3-6 (mingw special)
ld version: 2.11.90 (with BFD 2.11.90)
Build environment: Dev-cpp
Mingw runtime: 2.0
w32api verstion: 2.1
"Raw Input" functionality is missing.
The appropriate MSDN url is:
http://msdn.microsoft.com/library/en-
us/winui/winui/windowsuserinterface/userinput/rawinput.a
sp
----------------------------------------------------------------------
Comment By: Earnie Boyd (earnie)
Date: 2004-02-15 01:06
Message:
Logged In: YES
user_id=15438
The problem you report has caused modification in some fashion in the official CVS \
for the given package. The w32api and mingw-runtime official CVS reside in the \
winsup CVS directory tree for Cygwin. Those package CVS trees are periodically \
merged into the MinGW CVS tree. If you still find problems then please open a new \
report.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=751228&group_id=2435
--__--__--
_______________________________________________
MinGW-notify mailing list
MinGW-notify@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-notify
End of MinGW-notify Digest
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic