Prev: Graphics.DrawString character set problem
Next: MC9090 Install
From: Michael Ober on 10 Dec 2009 21:13
Yes and no. The fact that many net programmers don't understand the
underlying OS is a real problem and leads to this type of question. MS
could have prevented this issue by allowing mixed word size applications in
a single address space - it would have taken more effort on their part, but
you could mix 16 and 32 bit code in the same address space in earlier
versions of Windows.

Mike.

"Tim Roberts" <timr(a)probo.com> wrote in message
news:kq51i5hc4rkqvjpt4d4nbabod15okn71re(a)4ax.com...
> "Michael Ober" <obermd.@.alum.mit.edu.nospam> wrote:
>>
>>These aren't issues with dotNet itself. Rather, they are restrictions
>>Windows puts on its WOW64 (Windows 32 on Windows 64) subsystem.
>
> Well, that's a matter of semantics. It becomes a .NET issue in the sense
> that managed programmers are accustomed to setting "AnyCPU" as their
> platform, and don't think about the fact that the same binary will be a
> 64-bit application on 64-bit systems, and a 32-bit application on 32-bit
> systems.
> --
> Tim Roberts, timr(a)probo.com
> Providenza & Boekelheide, Inc.

From: Tim Roberts on 11 Dec 2009 23:27
"Michael Ober" <obermd.@.alum.mit.edu.nospam> wrote:
>
>Yes and no. The fact that many net programmers don't understand the
>underlying OS is a real problem and leads to this type of question. MS
>could have prevented this issue by allowing mixed word size applications in
>a single address space - it would have taken more effort on their part, but
>you could mix 16 and 32 bit code in the same address space in earlier
>versions of Windows.

Agreed. In my humble opinion, Microsoft screwed up many things in this
transition. SysWow64, file system redirection, registry redirection,
32-bit longs, etc; all of these things are just evidence that Microsoft
believed that developers were all too stupid to handle the transition
intelligently, despite the fact that we handled the 16-to-32 transition
just fine.
--
Tim Roberts, timr(a)probo.com
Providenza & Boekelheide, Inc.
From: Eric on 12 Dec 2009 18:24
On Thu, 10 Dec 2009 19:13:32 -0700, "Michael Ober"
<obermd.@.alum.mit.edu.nospam> wrote:

>Yes and no. The fact that many net programmers don't understand the
>underlying OS is a real problem and leads to this type of question. MS
>could have prevented this issue by allowing mixed word size applications in
>a single address space - it would have taken more effort on their part, but
>you could mix 16 and 32 bit code in the same address space in earlier
>versions of Windows.
>
>Mike.

Good points in this thread. I was just setting up a system for doing
Azure development, and was considering 64-bit Windows 7. Most of the
target app will be C#, but there will also be at least one legacy
native DLL in the picture. Any opinions on whether it would be better
to stay with 32-bit Windows 7 in this case? Or are there reliable
workarounds with Win7-64?
From: Peter Duniho on 12 Dec 2009 18:41
Eric wrote:
> Good points in this thread. I was just setting up a system for doing
> Azure development, and was considering 64-bit Windows 7. Most of the
> target app will be C#, but there will also be at least one legacy
> native DLL in the picture. Any opinions on whether it would be better
> to stay with 32-bit Windows 7 in this case? Or are there reliable
> workarounds with Win7-64?

The 32-bit DLL only means your program has to be 32-bit instead of "any"
or 64-bit. But it will still run fine on 64-bit Windows. I don't think
having 32-bit code to run is any reason to avoid 64-bit Windows. If you
have other reasons to upgrade to 64-bit Windows, you might as well.

Pete
From: Tom Shelton on 12 Dec 2009 19:52
On 2009-12-12, Eric <Eric@---nospam---.com> wrote:
> On Thu, 10 Dec 2009 19:13:32 -0700, "Michael Ober"
><obermd.@.alum.mit.edu.nospam> wrote:
>
>>Yes and no. The fact that many net programmers don't understand the
>>underlying OS is a real problem and leads to this type of question. MS
>>could have prevented this issue by allowing mixed word size applications in
>>a single address space - it would have taken more effort on their part, but
>>you could mix 16 and 32 bit code in the same address space in earlier
>>versions of Windows.
>>
>>Mike.
>
> Good points in this thread. I was just setting up a system for doing
> Azure development, and was considering 64-bit Windows 7. Most of the
> target app will be C#, but there will also be at least one legacy
> native DLL in the picture. Any opinions on whether it would be better
> to stay with 32-bit Windows 7 in this case? Or are there reliable
> workarounds with Win7-64?

I would still do 64-bit. You can isolate the 32-bit dll in a suragate
process or a com wrapper. This would allow the majority of your application
to target 64-bit, but still make use of the 32-bit code.

--
Tom Shelton
First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: Graphics.DrawString character set problem
Next: MC9090 Install