have this all wrong...
dw
--
Own the Future-Intel(R) Level Up Game Demo Contest 2013
Rise to greatness in Intel's independent game demo contest. Compete
for recognition, cash, and the chance to get your game on Steam.
$5K
ports, I think the inlines
are a better (more efficient) way to go.
dw
On 3/28/2013 3:52 AM, Václav Zeman wrote:
Why are those intrinsics even implemented using inline assembler
instead of GCC's own built-in functions like __builtin_ffs() for
_BitScanForward(), __sync_add_and_fetch
know well?
Also (exposing my ignorance here), how do the built-ins for gcc get
created? If (as I'm saying to kai) the definitions in winnt.h are
wrong, could that same code be what's used in the __builtins?
dw
--
Own
)
: memory
);
}
NB: I don't believe this definition of __stosb is quite right either.
But it's closer. And it does illustrate the behavior of the memory
clobber, which was the purpose of the post.
dw
--
Own
;
} c;
c.a = 1;
c.b = 2;
__stosb((PBYTE)c, 0, sizeof(c));
printf(%u %u\n, c.a, c.b); // Should print 0 0
}
The attached patch resolves this issue.
dw
Index: winnt.h
===
--- winnt.h (revision 5863)
+++ winnt.h (working
. It made things easier to
change while I was experimenting.
dw
--
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently
returns the old value.
2) Uses builtin function instead of inline asm.
dw
Index: winnt.h
===
--- winnt.h (revision 5867)
+++ winnt.h (working copy)
@@ -1416,37 +1416,22 @@
: memory);
return prev
implementation-file in
crt as separate implementations.
I respect your vision of how this should be laid out. I just wanted to
make sure I was clear about what I was proposing. If this is still the
way you prefer, that's what I'll do.
dw
re-work the patch I submitted for
InterlockedOr to use this same approach.
dw
Index: mingw-w64-crt/intrincs/__stosb.c
===
--- mingw-w64-crt/intrincs/__stosb.c(revision 5871)
+++ mingw-w64-crt/intrincs/__stosb.c(working copy
intrin-mac.h to avoid duplicating code.
dw
Index: mingw-w64-crt/intrincs/ilockand.c
===
--- mingw-w64-crt/intrincs/ilockand.c (revision 5872)
+++ mingw-w64-crt/intrincs/ilockand.c (working copy)
@@ -1,12 +1,7 @@
#include intrin.h
On 5/24/2013 8:43 PM, dw wrote:
I looked at the hand-crafted and the built-in, and they both generate
the same code. In the end, I went with the __sync_fetch_and_OP()
built-in (attached). The comments above still apply.
I'm going to wait for this patch to get committed before sending
not sure why this ever worked.
- I have added comments to intrin-mac.h describing the parameters for
the macros from previous patches.
dw
Index: mingw-w64-crt/intrincs/bittestci.c
===
--- mingw-w64-crt/intrincs/bittestci.c (revision
to MSVC, but it effectively produces the same results, and
will (at least on current processors) generate faster code.
Opinions?
dw
||
--
Get 100% visibility into Java/.NET code with AppDynamics Lite
It's a free
this?
There is a similar question for MemoryBarrier(). The mfence instruction
is SSE2. Check for __SSE2__ or not?
dw
--
How ServiceNow helps IT people transform IT departments:
1. A cloud service to automate IT design, transition
successful. Can you
produce a small sample?
dw
--
How ServiceNow helps IT people transform IT departments:
1. A cloud service to automate IT design, transition and operations
2. Dashboards that offer high-level views
needs changing is winnt.h. My
proposed patch is attached.
*Note that I am fudging a bit on __stosd, which MS declares as unsigned
long. I'm pretty sure this isn't what we want in gcc, so I've changed
this to unsigned int.
dw
Index: mingw-w64-crt/intrincs/__stosd.c
of the (somewhat bewildering)
fact that __LONG32 isn't always 32bits. I'm sure there's a good reason
for this, but I believe __stosd should always work 4 bytes at a time.
dw
--
This SF.net email is sponsored by Windows:
Build
.
dw
--
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
___
Mingw-w64-public mailing list
Mingw-w64-public
-32_CPUs_not_supporting_SSE2).
So, while I'm checking for __SSE2__ in the x86 branch, I'm not for x64.
Patch to come shortly.
dw
--
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows
__buildint to intrin-mac.h for DbgRaiseAssertionFailure __int2c.
8) On x86, if SSE2 is available, use _mm_pause for YieldProcessor and
_mm_mfence for MemoryBarrier. If SSE2 is not available, build the
appropriate asm (rep nop for pause and xchg for MemoryBarrier).
dw
Index: mingw-w64-headers/crt
ugly.
I've re-worked this one. Attached.
dw
Index: mingw-w64-headers/crt/intrin.h
===
--- mingw-w64-headers/crt/intrin.h (revision 5883)
+++ mingw-w64-headers/crt/intrin.h (working copy)
@@ -12,7 +12,18 @@
#include
(...
#endif
#endif
dw
--
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev___
Mingw-w64-public mailing list
Mingw-w64-public
be that if you want to use MSVC's intrinsic functions in gcc, you would
have to #include intrin.h.
I'd say that, ideally we'd put everything in #ifdef __MINGW_INTRIN_INLINE.
Ok by me. I just chose __CRT_INLINE because it seemed to be what other
code was using.
dw
#defines/prototypes? Or
do things actually end up getting linked in that wouldn't otherwise? If
the former, it doesn't sound like much of a problem. If the latter, I'd
like to take a look at it.
dw
--
This SF.net email
__SIZE_TYPE__ in alexey's output
http://pastebin.com/PaBMjAtr). If you are building for Windows, that
seems wrong.
dw
--
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows
So, having heard nothing back on this topic, I've decided to just try it
and see how it looks.
Below are the proposed contents of the new file intrin-impl.h, which
gets included at the bottom of intrin.h. It's still a little rough, but
it should be enough to decide if I'm heading in the right
be ready to
share it.
dw
--
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
___
Mingw-w64-public mailing list
Mingw-w64
of the effects of the memory
barrier. But just because sometimes it looks like it might be working
isn't the same as it being right.
dw
Index: mingw-w64-crt/intrincs/__faststorefence.c
===
--- mingw-w64-crt/intrincs
is ok. I would like that Jacek takes a closer look to it, too.
Good idea. It sounds like he has been thinking about this stuff for a
while.
dw
--
This SF.net email is sponsored by Windows:
Build for Windows Store
the file seemed to be. If using /* */ is the standard, somebody
tell me and I'll change mine plus the ones that were already using it.
dw (not actually a duck)
--
This SF.net email is sponsored by Windows:
Build
you feel about this?
dw
--
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
___
Mingw-w64-public mailing list
Mingw-w64
on in today, and will
probably give it a final look in a few hours. The only thing I've
changed so far is comments. In case you hadn't noticed, I'm a big
believer in comments.
I'm not sure when over night is where you are, but if you get the
chance, this would be helpful.
dw
While input parameters to asm blocks are expressions (not lvalues), they
cannot (safely) be modified within the asm code unless they are also
listed as outputs. While this may appear to work, code that comes
*after* the asm block may fail.
dw
Index: mingw-w64-headers/include/psdk_inc/intrin
kernel32.
dw
--
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
___
Mingw-w64-public mailing list
Mingw-w64-public
) Update intrinsics\*.c files that weren't fixed by other work.
Since #2 is giving the wrong answer, I'd like to get at least that one
included. Ideally I'd like to finish it all, but that depends on when
you plan to cutoff checkins for this version.
dw
specific?
dw
--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free
The pseh lib is 32 bit only. seh on 64 bit is different and btw
supported by gcc :)
I was hoping you'd say that. That means I don't have to try to change
any of it.
Thanks for the info.
dw
--
See everything from
is an input param
f) Support both att and intel asm formats for both __read* and __write*
3) Change NtCurrentTeb, GetCurrentFiber, and GetFiberData to use
existing routines instead of inline asm.
dw
Index: mingw-w64-crt/intrincs/currentfiber.c
duplicate the inline asm from elsewhere, calling
existing routines seemed the more sensible plan.
I might also point out that #3 only affects x86 code. The x64 code
already does it this way.
I'll wait for your final approval before committing.
dw
the makefile.in since I don't have the exact
version of automake.
dw
Index: mingw-w64-crt/Makefile.am
===
--- mingw-w64-crt/Makefile.am (revision 5949)
+++ mingw-w64-crt/Makefile.am (working copy)
@@ -470,7 +470,7
clobber.
f) Use symbolic names.
g) Support both att and intel asm formats.
dw
Index: mingw-w64-crt/intrincs/bitscanfwd.c
===
--- mingw-w64-crt/intrincs/bitscanfwd.c (revision 5949)
+++ mingw-w64-crt/intrincs/bitscanfwd.c (working copy
I believe JonY is halfway thru making a big change. That's why he had
me do the patch.
dw
On 7/14/2013 2:59 PM, Kai Tietz wrote:
Patch is ok. Please apply.
JonY could you regenerate Makefile for it?
Thanks in advance,
Kai
2013/7/13 dw limegreenso...@yahoo.com:
Here is the patch
is not an intrinsic, it is a macro defined
in winnt.h).
Inline functions are better way for forwarding calls, esp. in this case.
Ok by me, but shouldn't you do all 6?
dw
--
See everything from the browser to the database
, outputs, and constraints.
d) add cc clobber.
e) Use symbolic names.
f) Support both att and intel asm formats.
dw
Index: mingw-w64-crt/intrincs/bittest.c
===
--- mingw-w64-crt/intrincs/bittest.c(revision 5952)
+++ mingw-w64-crt
this problem.
dw
--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free
work if boost didn't have their own copy of the function
prototype.
Sorry Jacek, I liked your idea of changing this to inlining.
Before we surrender, is it worth talking to the boost people? Or should
I just change this back to use the DLL?
dw
On 7/15/2013 6:26 PM, Kai Tietz wrote:
yeah
has
_InterlockedExchange@8.constprop.0 and
__imp__InterlockedExchange@8.constprop.0.
Something is getting tangled here, but I'm not quite sure what.
dw
--
See everything from the browser to the database with AppDynamics
into doing something it
normally forbids. That seldom ends well.
I'd like to see this work. But I'm starting to lean back towards just
using the imports for x86.
dw
--
See everything from the browser to the database
Ping.
These have nothing to do with the boost/Interlocked* issues.
dw
On 7/15/2013 2:37 PM, dw wrote:
1) Move these functions to intrin-impl.h:
_bittest, _bittest64
_bittestandset, _bittestandreset, _bittestandcomplement
_bittestandset64, _bittestandreset64, _bittestandcomplement64
2
to always_inline if we can use inlines, and uses
dllimport as a fallback.
dw
Index: mingw-w64-headers/include/winbase.h
===
--- mingw-w64-headers/include/winbase.h (revision 5955)
+++ mingw-w64-headers/include/winbase.h (working copy)
@@ -995,6
for
__MINGW_INTRIN_INLINE. If that's important, then intrin-impl.h needs to
be updated as well.
I'd hope for better fallback on older (well, all currently released) GCC
versions, but I'm out of ideas now.
Between the gcc bug and people copying prototypes locally, there was
only so much we could do.
dw
by default.
Why? What problems do you envision?
To me this looks like trading future proof solution for speed.
Since MS has omitted these functions from the x64 version of
kernel32.dll and replaced them with inline versions, I'm not clear what
future problems you are expecting.
dw
to the library if that
seems like the right thing to do. But I could use some guidance about
what the right thing to do is.
dw
--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility
, is it likely
__MINGW_GNUC_PREREQ will be? Seems like we're just changing where the
compiler error occurs.
I hope Kai is okay with it and will review it when he's back.
Kai said that in his absence, you were able to approve checkins.
dw
could write the email, I'm not sure they'd listen to me. It's
not like they know who I am. Also, I've been told that my posts are
sometimes perceived as confrontational. And that's not a good thing for
this kind of effort.
dw
. If defining
BOOST_USE_WINDOWS_H is what's needed to work with our v3, this doesn't
seem to me like an unreasonable burden. Especially when it also gains
them performance improvements.
dw
--
See everything from the browser
and add the
defs back to avoid the conflict.
dw
--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root
Attached is the patch I came up with to fix the build issue.
You are checking for defined(__MINGW64_VERSION_MAJOR). Would it make
sense to do (__MINGW64_VERSION_MAJOR = 3)?
dw
--
See everything from the browser
the #ifdef for __MINGW_INTRIN_INLINE that jacek wanted for
intrin-impl.h.
dw
Index: mingw-w64-headers/include/psdk_inc/intrin-impl.h
===
--- mingw-w64-headers/include/psdk_inc/intrin-impl.h (revision 5971)
+++ mingw-w64-headers/include
://msdn.microsoft.com/en-us/library/ms684208%28v=VS.85%29.aspx
It's just an macro that's defined in winnt.h. Which we already do.
The attached patch does the delete. I can create the other patch
instead if that seems like a better approach.
dw
Index: intrincs/membarrier.c
,
dw
--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial
Done as 5980.
dw
On 7/23/2013 4:33 PM, dw wrote:
The patch looks good to me.
This patch requires re-building mingw-w64-crt/Makefile.in. Can
someone with the right autoconf do this checkin please? The
description should be something like:
Remove non-intrinsic function from intrinsic
Minor tweaks to bring defs in line with MS.
dw
Index: winnt.h
===
--- winnt.h (revision 5973)
+++ winnt.h (working copy)
@@ -1620,7 +1620,7 @@
#else
#define YieldProcessor __buildpause()
VOID MemoryBarrier(VOID);
-__CRT_INLINE
changes to inputs, outputs, constraints and clobbers.
d) Use macros symbolic names.
e) Support both att and intel asm formats.
dw
Index: mingw-w64-crt/intrincs/bittest.c
===
--- mingw-w64-crt/intrincs/bittest.c (revision 5980)
+++ mingw
Comments, flames, or questions?
I like this idea too.
dw
--
Get your SQL database under version control now!
Version control is standard for application code, but databases havent
caught up. So what steps can you
\crt\stdlib.h and
mingw-w64-headers\include\winnt.h do the same thing.
dw
--
Get your SQL database under version control now!
Version control is standard for application code, but databases havent
caught up. So what steps
Jacek, while I have checked in this patch so that I could continue work,
I would still be interested in any comments you might have on this.
dw
On 8/2/2013 12:12 AM, Kai Tietz wrote:
Jacek, do you have any objections about that patch
any
of these functions, I just assumed it was using msvcr*.dll for
everything. Hopefully I'm making more sense this time.
dw
--
Get your SQL database under version control now!
Version control is standard for application
at intrin-impl.h. There are several #if blocks there
- defined(__x86_64__)
- defined(__x86_64__) || (defined(_X86_)
- defined(_X86_)
The readcr* functions appear in both the __x86_64__ and _X86_ blocks
using different signatures.
dw
. Note that winnt.h has inlines for x86/x64 for these.
*Files deleted from intrincs*.
dw
Index: mingw-w64-crt/intrincs/__movsb.c
===
--- mingw-w64-crt/intrincs/__movsb.c (revision 6023)
+++ mingw-w64-crt/intrincs/__movsb.c (working
, but that doesn't appear to be true?
dw
--
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with 2
? Apply your patch? Define BOOST_USE_WINDOWS_H?
dw
On 8/20/2013 7:46 AM, Ruben Van Boxem wrote:
2013/8/20 Alex Hultman alexhult...@gmail.com
mailto:alexhult...@gmail.com
Hey!
I'm trying to figure out what libs to link with to get the
Interlocked*-API working. Google points me
can
reproduce the problem here.
This signature stuff has to stop.
dw
--
Introducing Performance Central, a new site from SourceForge and
AppDynamics. Performance Central is your source for news, insights,
analysis
of #define here, it would also be a good place
to document all this. I'm a big believer in capturing this kind of
knowledge, but you've got to have a place where people will find it.
dw
--
Introducing Performance Central
It's a really delayed reply, dw asked me to join the conversation.
Hey Jacek, thanks for you thoughts on this. However, it doesn't seem to
have brought us to a conclusion. I've been trying to avoid nagging
(something I am prone to do), especially since I've seen how busy Kai
has been
I agree on fixing wrong behavior of intrinsic-functions (and their
implementation files), but such changes please sent in separate
patches, so that I can review them stand-alone.
dw, can you please do that?
I'll try to parse these out into separate patches. There's some overlap
__movsb, __movsd, __movsq, __movsw: Move these intrinsics from
library-only to intrin-impl.
dw
Index: mingw-w64-crt/intrincs/__movsb.c
===
--- mingw-w64-crt/intrincs/__movsb.c (revision 6265)
+++ mingw-w64-crt/intrincs/__movsb.c
it seemed appropriate. However, if the text isn't
clear, I can re-word it.
dw
--
LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99!
1,500+ hours of tutorials including VisualStudio 2012, Windows 8
of issue with long vs long32. Is
sizeof(long) 32 or 64?
It might also be worth looking at the -E output. Perhaps you are
grabbing intrin.h and winbase.h from different mingw-w64 builds?
dw
--
LIMITED TIME SALE - Full Year
me) screaming for a fix. If we needed an immediate fix, I
could see going with #2, but the cleanest (and my current preference) is
#3.
I'm prepared to write #2 or #3 (or #4 if someone has a better idea), but
before I spend the time, I'd like to know which would get approved.
dw
: If the
timeout has already expired by the time of the call implies that an
absolute time is being specified, not a duration. While I think your
definition is more useful, this may result in unexpected behavior for
others.
FWIW,
dw
It sounds like you are missing libmsvcr100.a
dw
On 11/13/2013 9:34 AM, André Guerreiro wrote:
Hello all,
sorry if this is a really basic question, I'm a MingW newbie.
I'm trying to build this code with Mingw-w64 4.6.3
#include stdio.h
int main()
{
FILE *fp = fopen(SOME_FILE, r
. I'll look again
if we are serious about using it.
dw
--
DreamFactory - Open Source REST JSON Services for HTML5 Native Apps
OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access
Free app hosting. Or install
Are you setting the dwLength member to the size of the structure?
dw
On 11/17/2013 1:18 AM, niXman wrote:
Jim Michaels 2013-11-17 11:27:
it's returning failure.
I have even filled the MEMORYSTATUSEX struct with 0's using memset().
nothing about that function seems to work.
Hi,
Please
A few thoughts:
1) Shouldn't global_lock be __LONG32?
2) Would it make sense for the exchange on global_lock to be done as a
single operation (ie InterlockedCompareExchange)?
dw
On 12/5/2013 10:45 AM, Fanael Linithien wrote:
I came up with a patch that fixes the issue for me.
The patch
in ___w64_mingwthr_remove_key_dtor (at
least there is a free for it there), but apparently that routine never
gets called.
Maybe it was supposed to be freed in __mingwthr_run_key_dtors when it
gets called?
dw
--
CenturyLink Cloud
and LLP64.
If this is approved, someone else will have to commit it. git is not my
thing.
dw
On 7/20/2014 2:18 AM, Ozkan Sezer wrote:
Regarding gcc PR target/61662:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61662
http://gcc.gnu.org/viewcvs/gcc?view=revisionsortby=daterevision=212826
In our
On 7/26/2014 9:29 AM, JonY wrote:
On 7/26/2014 22:39, Ozkan Sezer wrote:
On 7/26/14, dw limegreenso...@yahoo.com wrote:
Well, since no one else has responded, what would you say to this
(attached)?
If you like, I can write up a detailed description about why I believe
this is the way to go
this incrementally, but
perhaps I should have gone straight to the final answer. This patch
adds _lrotl/_lrotr to intrin-impl instead of just fixing the
prototypes. Shouldn't be any surprises. Note that this is a
replacement for the other patch, not in addition to.
dw
diff --git a/mingw-w64-headers
PAGE_EXECUTE_WRITECOPY. Remember to change the comparison in
mark_section_writable() as well.
FWIW,
dw
On 8/15/2014 8:17 PM, Vadim Chugunov wrote:
Okay, I was wrong about __MINGW64_VERSION_MAJOR: it *was* defined.
What apparently happens is that the VirtualQuery() call that follows
Well, I've done what I can to diagnose this. It's up to the mingw devs
from here.
dw
On 8/19/2014 1:04 PM, Vadim Chugunov wrote:
No, sorry, I don't have the setup to build mingw. Not likely that I
will have time to do it any time soon either.
I meant this as a bug report. I hope the problem
On 9/20/2014 8:07 AM, André Hentschel wrote:
Am 19.09.2014 um 17:30 schrieb Kai Tietz:
2014-09-19 1:34 GMT+02:00 dw limegreenso...@yahoo.com:
For the parts that are working around a compiler bug:
- Does it make sense to list the bug number in the comment?
I think it makes sense in general
in different sections, please feel free to
enlighten me.
dw
On 8/19/2014 1:02 PM, Vadim Chugunov wrote:
No, sorry, I don't have the setup to build mingw. Not likely that I
will have time to do it any time soon either.
I meant this as a bug report. I hope the problem has been
investigated
Ups, that was unintended to send an empty mail :)
I did wonder. I assumed it was just a ping.
So, here is a patch.
Your patch does not look right. You have added the new checks using ||?
It would be great if somebody could verify that the reported
issue is solved by it.
Yes, this is
can't be freed until
application shutdown (or possibly at dll unload time) since it is used
right up until the last minute.
dw
From e9adda2479244cbf3681c379b2573362eace6308 Mon Sep 17 00:00:00 2001
From: David Wohlferd d...@limegreensocks.com
Date: Fri, 31 Oct 2014 20:00:04 -0700
Subject: [PATCH
program). Probably makes sense to
leave this alone. Not sure what the 16byte thing is, but it doesn't
seem to be cumulative, so I'm not much motivated to seek it out.
dw
On 10/31/2014 11:27 PM, lh_mouse wrote:
I have applied the patch and here are test results:
/// using
, that's less than 30 bytes.
Room to spare. So now when my32bitapp.exe is run, it turns around and
launches 16.exe. Tada!
dw
On 12/5/2014 2:26 PM, bulk 88 wrote:
Date: Fri, 5 Dec 2014 09:49:55 +0100
From: ktiet...@googlemail.com
To: mingw-w64-public@lists.sourceforge.net
Subject: Re
for, but perhaps it can give you
what you need?
dw
On 12/5/2014 2:26 PM, bulk 88 wrote:
Date: Fri, 5 Dec 2014 09:49:55 +0100
From: ktiet...@googlemail.com
To: mingw-w64-public@lists.sourceforge.net
Subject: Re: [Mingw-w64-public] adding dos stub program with ld to
PE binary
2014-12-05 6:45 GMT+01
sense at all?
If mingw-w64's stdlib.h doesn't need to support 8 byte longs, this patch
gets much easier. But if it does, what's the approach to test it?
dw
--
Dive into the World of Parallel Programming. The Go Parallel
.
dw
On 1/14/2015 9:33 AM, Greg Jung wrote:
Hi Folks,
I've been trying to program a recognition of NTFS symbolic link
files; What I;ve gleaned
from MSDN procedures don't seem to work. Below are coded three methods
1) (untested) open file and call GetFileInformationByHandleEx. I
can't get
1 - 100 of 122 matches
Mail list logo
