Groups:
* comp.arch because "that's my home", and the PC in question will
be used for computer architecture work
* also because I think that comp.arch should discuss
implications of tablets, 32->64 transition, etc.
* microsoft.public.windows.tabletpc because I am asking tablet PC
questions
* microsoft.public.windows.tabletpc.developer because my needs are
similar to those of a high end developer
* vmware.guest.misc because it is vmware related

---+ BRIEF: I am looking for advice/recommendations for what Tablet
PC I should purchase.

My requirements/desires:
* must be x86
* must be 64-bit capable - e.g. must be able to run instructions
such as 64 bit load to RAX
* should be a Tablet PC
* may run a 32 bit Tablet PC OS, if a 64-bit Tablet PC OS, and
associated device drivers, cannot be found
* must be able to run 64-bit code under VmWare or the
equivalent, if the main OS is 32-bit
* must run Microsft OSes such as Windows, Vista
* WHY: AFAIK there is no useful tablet PC support on Linux
* also, I need to connect to Intel's Windows ecosystem
* highly desirable to be able to run Linux in a virtual machine.
* should be a Tablet PC with a pen/stylus
* I like writing, not just touchscreen
* display must be at least 1024x768
* should be 1200x1024, or larger
* highly desirable if tablet can use LCD and external video as
independent display surfaces,
and can drive 1200x1024 or larger externally, even if limited
to 1024x768 on on LCD

I have had trouble finding such tablet PCs. Many tablet PCs, although
with 64-bit processors, are only available with 32-bit OSes, probably
because of device driver availability.

Any advice/pointers appreciated. Please email pcsearch@patten-
glew.net



---+ Detail

---++ BACKGROUND

I do computer architecture work, instruction set and microarchitecture
simulations. I like to work on my laptop, particularly when not
connected to the Internet. For the past few years I have been able to
get away with a 32-bit processor -- I have 32-bit simulators that can
simulate 64-bit stuf, albeit slowly -- but more and more I need to
have a 64-bit microprocessor in my laptop.


---++ PROBLEM: Intel's IT department does not support 64-bit
laptops.

Last I looked, Intel IT did not support 64-bit client OSes at all, but
my group was able to buy 64-bit clients, install our own 64-bit OSes,
and run them "unsupported" by IT. (E.g. if malware breaks in, we are
fined.)

But apparently our budget only allows us to buy "desktop" clients.
Apparently we cannot spend our own money to buy 64-bit laptops.

Apparently Intel IT is in the process of deploying 64-bit capable
laptops, but only running 32-bit OSes. Unfortunately, there appears to
be a rotation or schedule as to who gets upgraded to 64-bit, and I am
not on the schedule for such an upgrade any time soon.

I can do 64-bit work on our non-laptop systems. But I really want to
be able to work on my laptop. (When I am asked "Why haven't you
written a 64-bit simulator", my answer is "the machine I work on is 32-
bits".)


---++ WORKAROUND and RELATED ISSUES: Because Intel IT won't provide me
a 64-bit laptop, I am considering buying one for myself.

I will work through the issues of getting it connected to the Intel
network.

---+++ Tablet

However, in part because it is possible that I may end up not being
able to connect a personally owned laptop to the Intel network, I am
only interested in purchasing a computer I would use for my own
work. I am not interested in a laptop; I am only interested in
spending my own money on a convertible Tablet PC. (I have compromised
a bit: if I did not need a 64-bit mobile device at work, I wouldn't be
buying a PC at all; instead I would be spending my money on a smart
phone.)

There are a few Tablet PCs that have 64-bit Core 2 Duo processors.
However, so far whenever I look closely I always find that they are
only available with 32-bit OSes. I expect that this is because the
device drivers are only available in 32-bits.

==> if you know of a Tablet PC that runs 64-bits, with 64-bit
processor and OS, please tell me. I.e. one where I can install 64-
bit Vistual C++, and compile 64 bit code.

If there are any 64-bit Tablet PC OSes out there, it would solve the
remaining issues.

---+++ Virtual Machines

One possibility could be to run a 32-bit host OS, and then install
VmWare to run a 64-bit guest OS. However, last time I checked (last
year) VmWare could not do this. On our desktop 64-bit systems, we
installed 64-bit host OSes, which required that we not be supported by
IT, and then installed 32-bit VmWare guests, so that we could run 32
and 64 bit code on the same system. We were unable to run 64-bit
guests on 32-bit hosts.

I have since heard rumors that VmWare can now run 64-bit guests on 32-
bit host OSes. The sources are reputable, but I cannot find this
documented on VmWare's web pages. Since installing OSes on VmWare,
or native hardware, can be a pain, I was hoping that somebody could
confirm or deny this, so that I can avoid wasting time find out the
hard way.

Q: can VmWare run 64-bit guests on a 32-bit host OS, on a 64-bit
capable microprocessor?

I.e. if I buy a Tablet PC that only has a 32-bit OS, because of the
aforementioned device driver issues, but which has a 64-bit capable
microprocessor, can I install a 64-bit guest OS under VmWare?

---+++ Display Size

I like lots of pixels. Even on a small Tablet PC LCD, but especially
if the tablet PC can drive an external monitor.

The last Tablet PC I had (a Toshiba) could not drive the external
video independently of the tablet LCD. I.e. the external display
resolution had to be the same size as the tablet LCD.

On my current Intel supplied laptop, a Thinkpad T43p, I have grown
attached to having independent external and internal video. E,g. at
the moment I am sitting in front of a 1600x1200 external LCD, while my
laptop LCD is displaying 1400x1050 and is displaying "background"
information such as the task manager.

The various Tablet PC specs are not very clear as to whether they
support this sort of external display. The sales support question-
answerers all seem puzzled by what I ask for.

Therefore, I ask these newsgroups which tablet PCs support this sort
of indepedent internal and external displays.

---++ Conclusion

I may be searching for a product that does not exist. But I can
hope...

If I can find a Tablet PC running a 64-bit OS, most of my needs will
be met.

If VmWare can run 64 bit guests on top of a Tablet PC running a 32 bit
OS on a 64 bit CPU, most of my needs will be met.

This would leave only the display issue.

If necessary, I will fall back to using 1024x768 on a tablet - but I
know there are 1200x1024 TabletPCs. (Unfortunately, the only one I
have asked deeply about, a Toshiba tablet, says that only 32-bit Vista
can use the tablet.)

I don't know of any tablet with the independent external and internal
display. But I can give up on that.

I guess 64 bit is my only hard requirement.

comp.arch@patten-glew.net wrote:
> ---+ BRIEF: I am looking for advice/recommendations for what Tablet
> PC I should purchase.
>
> My requirements/desires:
> * must be x86
> * must be 64-bit capable - e.g. must be able to run instructions
> such as 64 bit load to RAX

I.e. any recent Intel (or AMD!) cpu.

> * should be a Tablet PC
> * may run a 32 bit Tablet PC OS, if a 64-bit Tablet PC OS, and
> associated device drivers, cannot be found
> * must be able to run 64-bit code under VmWare or the
> equivalent, if the main OS is 32-bit

This does work.

[big snip]

> I have since heard rumors that VmWare can now run 64-bit guests on 32-
> bit host OSes. The sources are reputable, but I cannot find this
> documented on VmWare's web pages. Since installing OSes on VmWare,
> or native hardware, can be a pain, I was hoping that somebody could
> confirm or deny this, so that I can avoid wasting time find out the
> hard way.
>
> Q: can VmWare run 64-bit guests on a 32-bit host OS, on a 64-bit
> capable microprocessor?

This does work very nicely, VMware 6 (6.02 is the current release) does
support 64-bit client OSs ona 32-bit host, as long as the CPU provides
the requisite virtualization support.

> ---+++ Display Size
>
> I like lots of pixels. Even on a small Tablet PC LCD, but especially
> if the tablet PC can drive an external monitor.

I'm using 1920x1200 + 1600x1200 on a pair of external monitors, with
XP-64 as my primary (host) OS and XP-32, Vista-64 and Linux-64 as client
machines, but unlike you I haven't fallen in love with tablets; i.e.
this is a regular (Fujitsu-Siemens C250) laptop with 4 GB ram.

It took me a few weeks before I got everything to work nicely with
XP-64, i.e. Nvidia's graphics drivers has/had a memory leak of about 20
kB/second, fortunately in an optional device driver which web searches
told me could be disabled. I also had troubles getting both external
monitors (via a port replicator) to be active at once, I finally had to
disable some BIOS video autosense parameters to make it work, and when
switching from laptop screen only (1680x1050) to the docked
configuration I have to manually disable monitor two, then use Fn+F10 to
switch (in order) to second (analog VGA) monitor only, analog+internal
in clone mode, then DVI external only, before I can close the laptop lid
and manually re-enable the VGA-connected second screen.

I don't need to do this very often though, because I've got exactly the
same setup at work and at home.

> On my current Intel supplied laptop, a Thinkpad T43p, I have grown
> attached to having independent external and internal video. E,g. at
> the moment I am sitting in front of a 1600x1200 external LCD, while my
> laptop LCD is displaying 1400x1050 and is displaying "background"
> information such as the task manager.
>
> The various Tablet PC specs are not very clear as to whether they
> support this sort of external display. The sales support question-
> answerers all seem puzzled by what I ask for.

My guess is that you'll find close to zero support for external monitors
with the tablet interface, i.e. you might have a tablet while traveling
and effectively a regular laptop when sitting at your desk.

Terje

PS. A few more pointers:

Visual Studio defaults to NOT include the 64-bit tools, _even_ when the
host machine is 64-bit Windows!

On both machines where I have tried this, VMware wouldn't handle 64-bit
clients initially because the cpu virtualization support was by default
disabled in the BIOS.

I've had a couple of hard system crashes (two in 2 weeks) which both
required a full rebuild of my primary machine, and they both seemed to
occur just as I was starting a VTune sampling run. This was while using
XP-32 as the host OS, and it was the main reason I switched to a new
laptop much sooner than I had intended to.

--
- <Terje.Mathisen@hda.hydro.com>
"almost all programming can be viewed as an exercise in caching"

Given that I recently highly recommended "Pin" for comp.arch work
(http://rogue.colorado.edu/pin/), y'all might be interested to learn
that the last straw that has compelled me to go shopping for a 64 bit
laptop, since Intel IT will not provide one, is Pin:

My simulators run fine - I can simulate 64 bit code on my old 32 bit
laptop. Slower than on a true 64 bit processor, but good enough for
debugging.

However, more and more I am using Pin to generate workload samples for
simulation. And Pin cannot run 64 bit apps on 32 bit processors.

That's not all that unreasonable a limitation. But it is compelling me
to go shopping for a 64 bit laptop earlier than Intel IT thinks I need
one.

---

The real moral for comp.arch is about the speed of transitions such as
32->64 bits: How long has 64 bits been available? And yet I still
don't have it in the PC I work on? If Intel IT lags so much, how can
you expect corporate IT or individual users to adopt new technology?

Glews observation:
IT departments are barriers to innovation and adoption.
(Except for technologies, such as virtualization or RAS or
manageability, that help IT departments do their job.

Corollary: it is easier to talk to a few IT departments than it is to
talk to lots of consumers. So it is easier to justify innovations
that make IT departments happy, rather than justify innovations that
make individuals happy.

This is just another flavor of Ward Christenson's "Innovator's
Dilemma".

---

There are similar issues with every new processor. Intel people
always complain that OS folks, such as Microsoft, are slow to adopt
and tune for new processors. But I'm totally on Microsoft's side
here: it's just plain easier to test and tune and evaluate your code
on the computers you use every day.

Sure, there will be dedicated people who are willing to test and
evaluate code for new processors on simulators. Or on special lab
machines. But there are fewer such people than there are generic
software developers.

You get into situations where the generic software developers churn
out untuned code, and the dedicated people who are using special
development vehicles are constantly playing catchup.

If you want code to be tuned and evaluated for new processors, you
need to make sure that as many software developers as possible are
using your processors on a daily basis. And even then there is a time
delay.

> I've had a couple of hard system crashes (two in 2 weeks) which both
> required a full rebuild of my primary machine, and they both seemed to
> occur just as I was starting a VTune sampling run. This was while using
> XP-32 as the host OS, and it was the main reason I switched to a new
> laptop much sooner than I had intended to.
>
> - <Terje.Mathisen@hda.hydro.com>

Terje's comment makes me wonder:

Is there natural selection pressure that increases the chances of such
bugs?

Since bugs like this often cause extra sales?

"comp.arch@patten-glew.net" <AndyGlew******.com> wrote in message
news:63e17f44-1a3e-44fa-be6f-6824900161c2@p69g2000hsa.googlegroups.com...
> Given that I recently highly recommended "Pin" for comp.arch work
> (http://rogue.colorado.edu/pin/), y'all might be interested to learn
> that the last straw that has compelled me to go shopping for a 64 bit
> laptop, since Intel IT will not provide one, is Pin:
>
> My simulators run fine - I can simulate 64 bit code on my old 32 bit
> laptop. Slower than on a true 64 bit processor, but good enough for
> debugging.
>
> However, more and more I am using Pin to generate workload samples for
> simulation. And Pin cannot run 64 bit apps on 32 bit processors.
>
> That's not all that unreasonable a limitation. But it is compelling me
> to go shopping for a 64 bit laptop earlier than Intel IT thinks I need
> one.
>
> ---
>
> The real moral for comp.arch is about the speed of transitions such as
> 32->64 bits: How long has 64 bits been available? And yet I still
> don't have it in the PC I work on? If Intel IT lags so much, how can
> you expect corporate IT or individual users to adopt new technology?

The real moral for comp.arch is the slow progress when a monopoly
supplier is dealing with a large installed base that is indifferent to
the transition. This applies to microsoft, Intel, and your IT
department.

The only reason that there is a 64 bit x86 is because AMD needed a lever.
Microsoft has no real reason to support 64 bits other than perhaps to
keep the government off their backs by supporting AMD. Your IT
department has no interest in anything that will make their job harder
unless there is considerable user demand leading to executive edict.

As deep throat said in the movies "follow the money".
(snip)

Del Cecchi wrote:
> "comp.arch@patten-glew.net" <AndyGlew******.com> wrote in message
>> The real moral for comp.arch is about the speed of transitions such as
>> 32->64 bits: How long has 64 bits been available? And yet I still
>> don't have it in the PC I work on? If Intel IT lags so much, how can
>> you expect corporate IT or individual users to adopt new technology?
>
> The real moral for comp.arch is the slow progress when a monopoly
> supplier is dealing with a large installed base that is indifferent to
> the transition. This applies to microsoft, Intel, and your IT
> department.
>
> The only reason that there is a 64 bit x86 is because AMD needed a lever.

I disagree.

> Microsoft has no real reason to support 64 bits other than perhaps to
> keep the government off their backs by supporting AMD. Your IT

I believe that's wrong.

> department has no interest in anything that will make their job harder
> unless there is considerable user demand leading to executive edict.

IMHO the key/sufficient reason for MS to develop a 64-bit Windows for
AMD-64 was quite simple:

Some very important customers require more than about 2GB of available
user memory, andif they can't have it, they will simply switch to
unix/linux.

This goes for all the server vendors, as well as workstations used for
both normal engineering/simulation work and for financial modeling.

It is significant that XP-64 first turned up in the form of the
server-only Windows-2003.

>
> As deep throat said in the movies "follow the money".

Always a good bet, particularly when/if Wall Street companies are big
buyers of 64-bit systems.

Terje

--
- <Terje.Mathisen@hda.hydro.com>
"almost all programming can be viewed as an exercise in caching"

comp.arch@patten-glew.net wrote:
> Given that I recently highly recommended "Pin" for comp.arch work
> (http://rogue.colorado.edu/pin/), y'all might be interested to learn
> that the last straw that has compelled me to go shopping for a 64 bit
> laptop, since Intel IT will not provide one, is Pin:
>
> My simulators run fine - I can simulate 64 bit code on my old 32 bit
> laptop. Slower than on a true 64 bit processor, but good enough for
> debugging.
>
> However, more and more I am using Pin to generate workload samples for
> simulation. And Pin cannot run 64 bit apps on 32 bit processors.

You might be able to do so running a 64-bit OS as a VMware client under
a 32-bit host OS.

> The real moral for comp.arch is about the speed of transitions such as
> 32->64 bits: How long has 64 bits been available? And yet I still
> don't have it in the PC I work on? If Intel IT lags so much, how can
> you expect corporate IT or individual users to adopt new technology?

You cannot.

>
> Glews observation:
> IT departments are barriers to innovation and adoption.

IT departments are almost universally measured by their "Service
Level/Uptime" performance, which means that it is in their best interest
to keep things as stable as humanly possible.

Replacing the entire OS infrastructure of a big organization is not
something you want to even contemplate before you're forced to do it.

> (Except for technologies, such as virtualization or RAS or
> manageability, that help IT departments do their job.

Right.

> If you want code to be tuned and evaluated for new processors, you
> need to make sure that as many software developers as possible are
> using your processors on a daily basis. And even then there is a time
> delay.

And even there you have heavy pressure to develop code that's compatible
with as many user machines as possible.

Case in point:

I have spent some weeks writing/optimizing what I believe is the worlds
fastest Ogg Vorbis decoder, it uses nothing but plain SSE in 32-bit mode
(and SSE2 in 64-bit mode, since that's guaranteed to be available).

It is significantly faster than the SSE3-based code which was my
benchmark target.

By staying within the SSE-only opcodes, I've ensured that effectively
all existing x86 machines will be able to run it, right?

Terje

--
- <Terje.Mathisen@hda.hydro.com>
"almost all programming can be viewed as an exercise in caching"

"Terje Mathisen" <terje.mathisen@hda.hydro.com> wrote in message
news:Ju6dnb6yn6wwsdjanZ2dnUVZ8s2mnZ2d@giganews.com ...
> Del Cecchi wrote:
>> "comp.arch@patten-glew.net" <AndyGlew******.com> wrote in message
>>> The real moral for comp.arch is about the speed of transitions such
>>> as
>>> 32->64 bits: How long has 64 bits been available? And yet I still
>>> don't have it in the PC I work on? If Intel IT lags so much, how can
>>> you expect corporate IT or individual users to adopt new technology?
>>
>> The real moral for comp.arch is the slow progress when a monopoly
>> supplier is dealing with a large installed base that is indifferent to
>> the transition. This applies to microsoft, Intel, and your IT
>> department.
>>
>> The only reason that there is a 64 bit x86 is because AMD needed a
>> lever.
>
> I disagree.

On what grounds? Intel's official 64 bit solution was Itanium. And they
denied having any interest in 64 bit X86 until AMD's success forced their
hand. Had it not been for AMD, x86 would have died at 32 bits.
>
>> Microsoft has no real reason to support 64 bits other than perhaps to
>> keep the government off their backs by supporting AMD. Your IT
>
> I believe that's wrong.

So what was Microsoft's motivation? I am cynical enough to know that
they weren't going to waste resources going to 64 bits just for the
benefit of the customer. Loss of market share to Linux might have done
it. Eventually they would have supported Windows of some type on
Itanium. I guess they did. But they had to if Intel and HP strategic
direction for 64 bits was Itanium.
>
>> department has no interest in anything that will make their job harder
>> unless there is considerable user demand leading to executive edict.
>
> IMHO the key/sufficient reason for MS to develop a 64-bit Windows for
> AMD-64 was quite simple:
>
> Some very important customers require more than about 2GB of available
> user memory, andif they can't have it, they will simply switch to
> unix/linux.

And what would they run this linux on if there were no 64 bit X86? And
was that a sufficient club to get microsoft to support it?
>
> This goes for all the server vendors, as well as workstations used for
> both normal engineering/simulation work and for financial modeling.
>
> It is significant that XP-64 first turned up in the form of the
> server-only Windows-2003.
>
>>
>> As deep throat said in the movies "follow the money".
>
> Always a good bet, particularly when/if Wall Street companies are big
> buyers of 64-bit systems.
>
> Terje
>
> --
> - <Terje.Mathisen@hda.hydro.com>
> "almost all programming can be viewed as an exercise in caching"

"comp.arch@patten-glew.net" <AndyGlew******.com> wrote in message
news:63e17f44-1a3e-44fa-be6f-6824900161c2@p69g2000hsa.googlegroups.com...
> There are similar issues with every new processor. Intel people
> always complain that OS folks, such as Microsoft, are slow to adopt
> and tune for new processors. But I'm totally on Microsoft's side
> here: it's just plain easier to test and tune and evaluate your code
> on the computers you use every day.

That's not actually Microsoft's problem. They turned out a 64-bit version
of Windows XP for AMD64 machines in a remarkably short time, once they
decided to do so, and it was very stable.

The problem is that Microsoft relies on other vendors to write the vast
majority of device drivers, and their driver model requires 64-bit drivers
if the kernel is 64-bit. Very few hardware vendors bothered writing 64-bit
drivers, or testing the ones they bothered recompiling, so XP64 didn't run
that well on many machines other than the ones Microsoft made the effort to
rewrite drivers for themselves.

It's similar to the reason that NT for Alpha, PPC, MIPS, and Itanic were all
stillborn: apps developers didn't bother to compile code for those
platforms, so they were limited to the (piss-poor) performance that was
available via emulation. The code ran, at least, but there was no reason
for IT departments to buy those machines when i386 machines could be had
with significantly better bang:buck ratios. And, of course, since nobody
bought the machines, no ISV was incented to compile for them; it was a
vicious cycle that anyone could have predicted.

MS finally figured out how to (mostly) solve the problem: to get the Vista
sticker, vendors had to provide both 32- and 64-bit drivers. Of course,
there's plenty of vendors that haven't shipped Vista "support" yet and tell
people to use XP32 drivers, but the better ones played ball, and in a few
years Vista64 will be almost as usable as Vista32. If they had done the
same with Win32, requiring vendors to compile for all platforms, x86's
deathgrip on Windows might have been broken a lot sooner.

Also, MS is pushing .NET pretty hard on developers, and the JIT compilation
means the underlying HW is mostly irrelevant at that point; if MS decides to
support a new arch tomorrow, all they have to do is port the CLR and all
existing .NET applications will run at near-optimal speeds immediately. Of
course, .NET also means MS no longer has lock-in via the Windows API, which
will mean long-term problems for their business model if it's actually
widely accepted...

S

--
Stephen Sprunk "God does not play dice." --Albert Einstein
CCIE #3723 "God is an inveterate gambler, and He throws the
K5SSS dice at every possible opportunity." --Stephen Hawking

The JITting of .NET code to any CPU architecture is great in theory. And in
one of my applications it actually worked out really well "by accident" when
I needed to exceed the 2GB memory limit on a 64 bit CPU. But in reality,
it's much harder for .NET apps to break free from 32 bit legacy. Many .NET
apps rely on COM or P/Invoke. Most of the time, COM components aren't
available for both 32 and 64 bits and P/Invoke requires special care to
write portable code. Also, applications which run in a host such as Office
applications, Internet Explorer, or even the shell are stuck in whatever
architecture their host is.

Having said that though, it's soooooo much easier to think about supporting
64 bits as a .NET developer. It's just not a magical switch unfortunately.

--
Josh Einstein (Tablet PC MVP)
Einstein Technologies
Tablet Enhancements for Outlook - Try it free: www.tabletoutlook.com


"Stephen Sprunk" <stephen@sprunk.org> wrote in message
news:fiadjd$21o$3@aioe.org...
> Also, MS is pushing .NET pretty hard on developers, and the JIT
> compilation means the underlying HW is mostly irrelevant at that point; if
> MS decides to support a new arch tomorrow, all they have to do is port the
> CLR and all existing .NET applications will run at near-optimal speeds
> immediately. Of course, .NET also means MS no longer has lock-in via the
> Windows API, which will mean long-term problems for their business model
> if it's actually widely accepted...
>
> S
>
> --
> Stephen Sprunk "God does not play dice." --Albert Einstein
> CCIE #3723 "God is an inveterate gambler, and He throws the
> K5SSS dice at every possible opportunity." --Stephen Hawking

Del Cecchi wrote:
> "Terje Mathisen" <terje.mathisen@hda.hydro.com> wrote in message
> news:Ju6dnb6yn6wwsdjanZ2dnUVZ8s2mnZ2d@giganews.com ...
>> Del Cecchi wrote:
>>> The only reason that there is a 64 bit x86 is because AMD needed a
>>> lever.
>> I disagree.
>
> On what grounds? Intel's official 64 bit solution was Itanium. And they

OK, I agree:

If Itanium had been the success Intel intended, then AMD wouldn't have
had the same opportunity to hijack the x86 architecture the way they did.

Terje

--
- <Terje.Mathisen@hda.hydro.com>
"almost all programming can be viewed as an exercise in caching"

In comp.arch Stephen Sprunk <stephen@sprunk.org> wrote:

> course, .NET also means MS no longer has lock-in via the Windows API, which
> will mean long-term problems for their business model if it's actually
> widely accepted...

There is a kind of lock-in. Take a look at the WinForms for example, it is
pretty much like the native Win32 API. Although of course it is possible to
implement the API in any other platform..

--
Jyrki Saarinen
http://koti.welho.com/jsaari88/

WinForms is nothing like the native Win32 API (thank god) unless you start
getting into the implementation and handling messages or custom drawing.
It's very well abstracted and Mono has done a good job of implementing it on
other platforms. Plus WPF is abstracted even more and doesn't even use the
traditional paint cycle. Of course WPF is pretty tied into DirectX at an
implementation level simply because it'd be so much work to implement on
another platform.

--
Josh Einstein (Tablet PC MVP)
Einstein Technologies
Tablet Enhancements for Outlook - Try it free: www.tabletoutlook.com


"Jyrki Saarinen" <jyrki@NOSPAMwelho.com.invalid> wrote in message
news:fieulg$jur$1@nyytiset.pp.htv.fi...
> In comp.arch Stephen Sprunk <stephen@sprunk.org> wrote:
>
>> course, .NET also means MS no longer has lock-in via the Windows API,
>> which
>> will mean long-term problems for their business model if it's actually
>> widely accepted...
>
> There is a kind of lock-in. Take a look at the WinForms for example, it is
> pretty much like the native Win32 API. Although of course it is possible
> to
> implement the API in any other platform..
>
> --
> Jyrki Saarinen
> http://koti.welho.com/jsaari88/
>

"Josh Einstein" <josh@einsteintech.net> wrote in message
news:3D4F1686-F52A-4385-BDB7-D56D24197A02@microsoft.com...
> The JITting of .NET code to any CPU architecture is great in theory.
> And in one of my applications it actually worked out really well "by
> accident" when I needed to exceed the 2GB memory limit on a 64
> bit CPU. But in reality, it's much harder for .NET apps to break free
> from 32 bit legacy. Many .NET apps rely on COM or P/Invoke. Most
> of the time, COM components aren't available for both 32 and 64
> bits and P/Invoke requires special care to write portable code.

Any use of P/Invoke is inherently nonportable. That doesn't mean there's a
way around it, since you may be using libraries that aren't available as
..NET components, but minimizing its use should be a major goal.

Since I've avoided COM like the plague, I wasn't aware of the problem mixing
it with .NET. That doesn't surprise me; COM is an evil hack. I'm sure MS
is working on a COM.NET framework, though, if some other replacement doesn't
already exist.

> Also, applications which run in a host such as Office applications,
> Internet Explorer, or even the shell are stuck in whatever architecture
> their host is.

That's probably the biggest factor holding .NET back; one has to ask, if
it's so great, why hasn't Microsoft adopted it for their own apps?

> Having said that though, it's soooooo much easier to think about
> supporting 64 bits as a .NET developer. It's just not a magical switch
> unfortunately.

Few things are.

S

--
Stephen Sprunk "God does not play dice." --Albert Einstein
CCIE #3723 "God is an inveterate gambler, and He throws the
K5SSS dice at every possible opportunity." --Stephen Hawking

> Since I've avoided COM like the plague, I wasn't aware of the problem
> mixing it with .NET. That doesn't surprise me; COM is an evil hack. I'm
> sure MS is working on a COM.NET framework, though, if some other
> replacement doesn't already exist.

COM interop is already there and has been since 1.0. It's necessary and I'm
guessing you haven't done much work with COM because if so you wouldn't be
calling it an evil hack. :) Some of the ideas of COM that were lost in the
move to .NET are extremely limiting, such as hidden interface
implementations, delegation, etc. The idea of a .NET class that provides an
implicit interface that cannot be implemented is quite frustrating when
coupled with the lack of multiple inheritence. But that's all getting off
topic. My point about .NET apps bound to COM not being portable has to do
with the fact that the COM components are rarely available in 64 bit flavors
and since a process can't mix 32 bit and 64 bit executables, you're S.O.L.

> That's probably the biggest factor holding .NET back; one has to ask, if
> it's so great, why hasn't Microsoft adopted it for their own apps?

Because rewriting Office in .NET would take a huge amount of time *just* to
get to where they are now, not adding any new features. And the customers
don't really count "rewritten in .NET" as a huge feature worthy of upgrading
to. Not to mention the fact that doing so would inevitably break every
solution built on Office.

They do use .NET for many newer products. MS CRM, Office Accounting,
Business Contact Manager, etc are all Office products that are developed
with .NET.

There is (or was last time I visited) a strong anti-.NET bias from the
operating system developers which is probably why there is no .NET code
running in Vista out of the box. But eventually these dinosaurs will be out
and replaced by people who get the idea of managed API's and applications as
first-class citizens.

--
Josh Einstein (Tablet PC MVP)
Einstein Technologies
Tablet Enhancements for Outlook - Try it free: www.tabletoutlook.com