The functions do not start with underscore or any other common prefix when
viewed in Depends, so I'll presume stdcall.
Thanks for the tip.
-Mont
On 4/30/07, Stoyan Damov <[EMAIL PROTECTED]> wrote:
open the dll in dependency walker (part of sysinternals suite) - if
your functions start with u
open the dll in dependency walker (part of sysinternals suite) - if
your functions start with underscore (_) they're almost certain cdecl,
otherwise probably stdcall.
On 4/30/07, Mont Rothstein <[EMAIL PROTECTED]> wrote:
Thanks for all of the information. I'll have to dig into this more.
The m
Thanks for all of the information. I'll have to dig into this more.
The make file doesn't have a /Gd or a /Gz flag. I suspect I am going to
have to contact the vendor about this (though I don't hold out much hope for
an answer).
I have C code that calls the same functions and works fine, so I
I believe the calling convention has to be __cdecl for the PInvoke to work,
but I may be wrong about that.
yup, wrong about that - all (except a few) Win32 API functions use
stdcall - because stdcall functions clean up the stack after
themselves, your code gets (a bit) smaller (and that's the r
I have a strong recollection that when I did my P/Invoke work a few months
ago, I ran into a problem where I had to look at the calling convention.
So as I recall I think it does matter; it would stand to reason that you
would have to P/Invoke the API using the same calling convention that the
API
Thanks for the additional info.
I am compiling this DLL with VS 05 form the command line. It uses a
manually created make file and not a project.
I didn't create the DLL, it is part of a package, which is why I am unclear
on some of this.
I searched the directory where all of the source is kep
Yes and yes. As far as .NET, from v.2.0 (I haven't looked at this in a
while, so please correct me), but the same binaries that you create for .NET
2.0 will run natively in 64 bit (as they are JIT compiled as 64 bit
instructions on those OS's).
Thanks,
Shawn Wildermuth
http://adoguy.com
http://w
The only time I've seen this happen is when you're using async handlers. I
don't think this will happen with sync handlers.
On 4/30/07, Fernando Tubio <[EMAIL PROTECTED]> wrote:
Frans said...
> ASP.NET can switch threads for a single request under high
> load (to prevent slow, heavy requests s
Can you generate a 64 bit .Net application for 64 bit Windows? What about
SQL Server? Can it run on a 64 bit back end server?
===
This list is hosted by DevelopMentor® http://www.develop.com
View archives and manage your subscription(s) at http://discuss.develo
I need to point out that this implementation only guarantees that
userService_ will only be initialized once;
ContainerWebAccessorUtil.Container is not thread-safe, and
ContainerType.Resolve ditto, but you can make them be thread-safe.
On 4/30/07, Stoyan Damov <[EMAIL PROTECTED]> wrote:
public s
public static SiteUser LoadCurrentUser()
{
...
if (userService_ == null)
{
lock (userServiceMx_)
{
if (userService_ == null)
{
IUserService service =
ContainerWebAccessorUtil.Container.Resolve();
Thread.MemoryBarrier();
I'm building a splash screen for a .Net 3.0 WPF app. The SplashScreen class
needs to load a bitmap (.png) using Win32 functions but I'm having trouble
figuring out how to add the bitmap to my project so it is visible to
(Win32)FindResource and then determine what the ResourceID or ResourceName
is
> Frans said...
>
> > ASP.NET can switch threads for a single request under high
> > load (to prevent slow, heavy requests starve small ones).
>
> I'm curious about this but I don't think I have ever actually come accross
> any documentation where this is discussed. Do you have any references you
>
Frans said...
ASP.NET can switch threads for a single request under high
load (to prevent slow, heavy requests starve small ones).
I'm curious about this but I don't think I have ever actually come accross
any documentation where this is discussed. Do you have any references you
could point me
14 matches
Mail list logo
