Re: Windows Internals 6th edition

> > Aren’t those links just to rip-off sites? I notice that the books are > still available for purchase elsewhere. > Ooops I dunno, I linked to the first pictures of the covers I could find in a Google. I just assumed they were some generic book website. I hope I haven't accidentally endorsed som

RE: Windows Internals 6th edition

Aren't those links just to rip-off sites? I notice that the books are still available for purchase elsewhere. Regards, Greg Dr Greg Low 1300SQLSQL (1300 775 775) office | +61 419201410 mobile│ +61 3 8676 4913 fax SQL Down Under | Web: www.sqldownund

Re: Windows Internals 6th edition

Wow I'm still digesting the Vista one :-) On 16 January 2014 14:21, Greg Keogh wrote: > Folks, just FYI - I had two books just arrive by courier: Windows > Internals Part-1 and > Windows > Internals Part-2

Windows Internals 6th edition

Folks, just FYI - I had two books just arrive by courier: Windows Internals Part-1 and Windows Internals Part-2 I had no idea until I looked just now, but both books are available as PDFs from He

Mixing platforms

If there are no specific reasons to use 64bit process - why not target 32bit version of .net? That way no issue with 32bit dll, you can freely use it. On Wednesday, 15 January 2014, Greg Keogh wrote: >> You have 32bit runtime installed on that box? > > I guess so, I have seen the pairs of folders

Inter-Process isolation

Folks, I knew it would work, but just in case it's of interest I can report that a parent Any CPU process can start a child x86 process which can Interop with native 32-bit DLLs. I opened a mini WCF server with TCP binding in the child and a corresponding WCF client in the parent. Then the parent

WebApp Monitoring

Hi, We are deploying a new instance of our app for a customer and we need a good monitoring for the app (web, sql, mongo, disk, ) We currently use Datadog (www.datadog.com) but I think it's missing some functionality (e.g. ping a webpage). What are some great tools for monitoring a web app (

RE: Mixing platforms

There's a few different ways off the top of my head to do cross-process communication in .NET above and beyond what Windows provides (such as named pipes, RPC): - .NET Remoting - WCF - Raw HTTP via network loopback Just do a .NET search and you'll see a variety of

RE: Changing from VS 2013 Ultimate Trial to purhcsing Professional

Agreed - I was given a friends pc recently to have a look at complaining about why they were running sql server and a complete VS2012 on her machine as it taking forever to crank up. Apparently her son had installed a trial of VS2012 - with everything installed - this machine was not a developme

RE: Changing from VS 2013 Ultimate Trial to purhcsing Professional

Nope. If you've installed as Ultimate it won't accept your Professional key as valid. You'll need to uninstall the trial and re-install. PS: In future you should consider using a VM when you want to trial-install something as pervasive as Visual Studio. From: ozdotnet-boun...@ozdotnet.com [mail

Changing from VS 2013 Ultimate Trial to purhcsing Professional

Hello I have been enjoying the trial version of VS 2013 ultimate, but all things considered would rather purchase a Professional edition when the trial expiers. Is it possible to get the Professional key and disable some features of ultimate instead of uninstalling Ultimate and installing the Pro

Re: Mixing platforms

> > If it’s managed, and no native, why not a simple recompile? > My experiment with Any CPU calling x86 was a sanity check before expanding to isolate some real native code. There are multiple issues at play here ... I will soon be given a fresh Borland C++ DLL which used to be a COM server, but

RE: Mixing platforms

If it's managed, and no native, why not a simple recompile? From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] On Behalf Of Greg Keogh Sent: Wednesday, January 15, 2014 12:29 AM To: ozDotNet Subject: Re: Mixing platforms A windows process is either 32-bit or 64-bit, never

Re: Mixing platforms

> > A windows *process* is either 32-bit or 64-bit, never both. There is no > such thing as an "Any CPU" *process*. A 64-bit process cannot load 32-bit > object code, ever[1]. > >On 64-bit Windows, a 64-bit process cannot load a 32-bit dynamic-link library (DLL). Well, that's the definitive state