Mapi32 and Vista

? But I wonder what you think you are compensating for.

I don't know about continental USA but throughout Asia, Australia and
Europe, time servers are basically never inaccurate. Too much is at
stake. It would be more appropriate to say that some may be different or
sometimes not available but then that is why you establish at least 7 or
8 in your DC and set parameters accordingly.

What I understand from reading various white papers in the US is that
the best free time servers are the US Navy ones and I think they would
be amused to think that you thought they were not accurate. Alternately
there are paid for time synch services that are guaranteed to be
accurate.

So no, I don't see a circumstance where an application should try to
duplicate this whole international effort on time synchronisation. Do
you also write word processors? <g>.

Geoff


"Ginny Caughey" <ginny.caughey.online@wasteworks.com> wrote in message
news:48c3c83e$0$21800$c3e8da3@news.astraweb.com:

> Geoff,
>
> Just because you can't see how the servers could become inaccurate doesn't
> mean it doesn't happen in practice.
>
> --
>
> Ginny Caughey
> www.wasteworks.com
>
>
>
> "Geoff Schaller" <geoffx@softxwareobjectives.com.au> wrote in message
> news:48c3c2cd@dnews.tpgi.com.au...
>
> > But this is difficult.... certainly in a domain scenario. In essence it
> > should be the domain that is sync'd and then workstations with the DC.
> > Once you go EBS and SBS you risk significant problems if you time sync in
> > any other way.
> >
> > But ok, if this is a totally standalone system then I guess there is
> > something in the original requirement but I wonder about your statement
> > about time servers. Mostly we should choose 7 or 8 servers to use on our
> > DC and set the comparator ranges appropriately. I don't see how they could
> > become inaccurate.
> >
> > Geoff
> >
> >
> > "Ginny Caughey" <ginny.caughey.online@wasteworks.com> wrote in message
> > news:48c3c0ef$0$3376$c3e8da3@news.astraweb.com:
> >
>
> >> Not always, Geoff. I have an app that syncs data between different
> >> servers,
> >> and it also syncs the system times. This is necessary because the time
> >> servers are not accurate enough.
> >>
> >> --
> >>
> >> Ginny Caughey
> >> www.wasteworks.com
> >>
> >>
> >>
> >> "Geoff Schaller" <geoffx@softxwareobjectives.com.au> wrote in message
> >> news:48c37c1f$1@dnews.tpgi.com.au...
> >>
>
> >> > Danilo.
> >> >
> >> > This is not correct. In Vista and XP you simply set the settings to the
> >> > correct time server (either your domain controller or for a stand alone
> >> > PC, the ISP's time server) and it happens for you.
> >> >
> >> > You certainly should not be doing this from your application. It is a
> >> > Windows level thing and must be independent from applications. Look up
> >> > Net
> >> > Time in google.
> >> >
> >> > Geoff
> >> >
> >> >
> >>
>
> >> >>
> >> >> At a point in my application I have to synchronize the time the
> >> >> internal
> >> >> clock, and therefore my application must have administrator rights.
> >> >>
> >> >> In. Net as you do it ? (to elevate your application to administrative
> >> >> level)
> >> >>
> >> >> Thanks
> >> >>
> >> >> Danilo
> >>
> >> >
>
> >

Geoff,

You just don't get it. I need servers to be synced with each other to the
millisecond at the time I sync the data. Even if they all use the same
(accurate or otherwise) time server, they still don't always have the exact
same time when I go to sync. I don't know why, and it doesn't really matter.
It's sort of like not knowing why VO does the things it does throughout all
the years. What I need is a workaround, and setting the system clocks of the
spoke servers in my hub and spoke topology at the time of sync if needed is
such a workaround. I don't worry about the times of the workstations at all,
since data is stamped with the server's time, not the workstation's in my
apps. Generally workstations are synced with the domain, but I don't allow
whether they are or not to be my problem.

And no, I don't write word processors, web servers, or email clients or
servers. I also don't write my own encryption algorithms or XML parsers
except for fun. I only do this stuff in production apps when there is no
working alternative.
--

Ginny Caughey
www.wasteworks.com



"Geoff Schaller" <geoffx@softxwareobjectives.com.au> wrote in message
news:48c45404@dnews.tpgi.com.au...
>? But I wonder what you think you are compensating for.
>
> I don't know about continental USA but throughout Asia, Australia and
> Europe, time servers are basically never inaccurate. Too much is at stake.
> It would be more appropriate to say that some may be different or
> sometimes not available but then that is why you establish at least 7 or 8
> in your DC and set parameters accordingly.
>
> What I understand from reading various white papers in the US is that the
> best free time servers are the US Navy ones and I think they would be
> amused to think that you thought they were not accurate. Alternately there
> are paid for time synch services that are guaranteed to be accurate.
>
> So no, I don't see a circumstance where an application should try to
> duplicate this whole international effort on time synchronisation. Do you
> also write word processors? <g>.
>
> Geoff
>
>
> "Ginny Caughey" <ginny.caughey.online@wasteworks.com> wrote in message
> news:48c3c83e$0$21800$c3e8da3@news.astraweb.com:
>
>> Geoff,
>>
>> Just because you can't see how the servers could become inaccurate
>> doesn't
>> mean it doesn't happen in practice.
>>
>> --
>>
>> Ginny Caughey
>> www.wasteworks.com
>>
>>
>>
>> "Geoff Schaller" <geoffx@softxwareobjectives.com.au> wrote in message
>> news:48c3c2cd@dnews.tpgi.com.au...
>>
>> > But this is difficult.... certainly in a domain scenario. In essence it
>> > should be the domain that is sync'd and then workstations with the DC.
>> > Once you go EBS and SBS you risk significant problems if you time sync
>> > in
>> > any other way.
>> >
>> > But ok, if this is a totally standalone system then I guess there is
>> > something in the original requirement but I wonder about your statement
>> > about time servers. Mostly we should choose 7 or 8 servers to use on
>> > our
>> > DC and set the comparator ranges appropriately. I don't see how they
>> > could
>> > become inaccurate.
>> >
>> > Geoff
>> >
>> >
>> > "Ginny Caughey" <ginny.caughey.online@wasteworks.com> wrote in message
>> > news:48c3c0ef$0$3376$c3e8da3@news.astraweb.com:
>> >
>>
>> >> Not always, Geoff. I have an app that syncs data between different
>> >> servers,
>> >> and it also syncs the system times. This is necessary because the time
>> >> servers are not accurate enough.
>> >>
>> >> --
>> >>
>> >> Ginny Caughey
>> >> www.wasteworks.com
>> >>
>> >>
>> >>
>> >> "Geoff Schaller" <geoffx@softxwareobjectives.com.au> wrote in message
>> >> news:48c37c1f$1@dnews.tpgi.com.au...
>> >>
>>
>> >> > Danilo.
>> >> >
>> >> > This is not correct. In Vista and XP you simply set the settings to
>> >> > the
>> >> > correct time server (either your domain controller or for a stand
>> >> > alone
>> >> > PC, the ISP's time server) and it happens for you.
>> >> >
>> >> > You certainly should not be doing this from your application. It is
>> >> > a
>> >> > Windows level thing and must be independent from applications. Look
>> >> > up
>> >> > Net
>> >> > Time in google.
>> >> >
>> >> > Geoff
>> >> >
>> >> >
>> >>
>>
>> >> >>
>> >> >> At a point in my application I have to synchronize the time the
>> >> >> internal
>> >> >> clock, and therefore my application must have administrator rights.
>> >> >>
>> >> >> In. Net as you do it ? (to elevate your application to
>> >> >> administrative
>> >> >> level)
>> >> >>
>> >> >> Thanks
>> >> >>
>> >> >> Danilo
>> >>
>> >> >
>>
>> >
>

Ginny,

I do get it but you are speaking of needing is extremely rare and I
doubt the need the original correspondent was after in the first place.
So let's get this into context. I don't know why you need this and you
haven't explained but I suspect it isn't the circumstance being
discussed.

Geoff



"Ginny Caughey" <ginny.caughey.online@wasteworks.com> wrote in message
news:48c50d6e$0$2095$c3e8da3@news.astraweb.com:

> Geoff,
>
> You just don't get it. I need servers to be synced with each other to the
> millisecond at the time I sync the data. Even if they all use the same
> (accurate or otherwise) time server, they still don't always have the exact
> same time when I go to sync. I don't know why, and it doesn't really matter.
> It's sort of like not knowing why VO does the things it does throughout all
> the years. What I need is a workaround, and setting the system clocks of the
> spoke servers in my hub and spoke topology at the time of sync if needed is
> such a workaround. I don't worry about the times of the workstations at all,
> since data is stamped with the server's time, not the workstation's in my
> apps. Generally workstations are synced with the domain, but I don't allow
> whether they are or not to be my problem.
>
> And no, I don't write word processors, web servers, or email clients or
> servers. I also don't write my own encryption algorithms or XML parsers
> except for fun. I only do this stuff in production apps when there is no
> working alternative.
> --
>
> Ginny Caughey
> www.wasteworks.com
>
>
>
> "Geoff Schaller" <geoffx@softxwareobjectives.com.au> wrote in message
> news:48c45404@dnews.tpgi.com.au...
>
> >? But I wonder what you think you are compensating for.
> >
> > I don't know about continental USA but throughout Asia, Australia and
> > Europe, time servers are basically never inaccurate. Too much is at stake.
> > It would be more appropriate to say that some may be different or
> > sometimes not available but then that is why you establish at least 7 or 8
> > in your DC and set parameters accordingly.
> >
> > What I understand from reading various white papers in the US is that the
> > best free time servers are the US Navy ones and I think they would be
> > amused to think that you thought they were not accurate. Alternately there
> > are paid for time synch services that are guaranteed to be accurate.
> >
> > So no, I don't see a circumstance where an application should try to
> > duplicate this whole international effort on time synchronisation. Do you
> > also write word processors? <g>.
> >
> > Geoff
> >
> >
> > "Ginny Caughey" <ginny.caughey.online@wasteworks.com> wrote in message
> > news:48c3c83e$0$21800$c3e8da3@news.astraweb.com:
> >
>
> >> Geoff,
> >>
> >> Just because you can't see how the servers could become inaccurate
> >> doesn't
> >> mean it doesn't happen in practice.
> >>
> >> --
> >>
> >> Ginny Caughey
> >> www.wasteworks.com
> >>
> >>
> >>
> >> "Geoff Schaller" <geoffx@softxwareobjectives.com.au> wrote in message
> >> news:48c3c2cd@dnews.tpgi.com.au...
> >>
>
> >> > But this is difficult.... certainly in a domain scenario. In essence it
> >> > should be the domain that is sync'd and then workstations with the DC.
> >> > Once you go EBS and SBS you risk significant problems if you time sync
> >> > in
> >> > any other way.
> >> >
> >> > But ok, if this is a totally standalone system then I guess there is
> >> > something in the original requirement but I wonder about your statement
> >> > about time servers. Mostly we should choose 7 or 8 servers to use on
> >> > our
> >> > DC and set the comparator ranges appropriately. I don't see how they
> >> > could
> >> > become inaccurate.
> >> >
> >> > Geoff
> >> >
> >> >
> >> > "Ginny Caughey" <ginny.caughey.online@wasteworks.com> wrote in message
> >> > news:48c3c0ef$0$3376$c3e8da3@news.astraweb.com:
> >> >
> >>
>
> >> >> Not always, Geoff. I have an app that syncs data between different
> >> >> servers,
> >> >> and it also syncs the system times. This is necessary because the time
> >> >> servers are not accurate enough.
> >> >>
> >> >> --
> >> >>
> >> >> Ginny Caughey
> >> >> www.wasteworks.com
> >> >>
> >> >>
> >> >>
> >> >> "Geoff Schaller" <geoffx@softxwareobjectives.com.au> wrote in message
> >> >> news:48c37c1f$1@dnews.tpgi.com.au...
> >> >>
> >>
>
> >> >> > Danilo.
> >> >> >
> >> >> > This is not correct. In Vista and XP you simply set the settings to
> >> >> > the
> >> >> > correct time server (either your domain controller or for a stand
> >> >> > alone
> >> >> > PC, the ISP's time server) and it happens for you.
> >> >> >
> >> >> > You certainly should not be doing this from your application. It is
> >> >> > a
> >> >> > Windows level thing and must be independent from applications. Look
> >> >> > up
> >> >> > Net
> >> >> > Time in google.
> >> >> >
> >> >> > Geoff
> >> >> >
> >> >> >
> >> >>
> >>
>
> >> >> >>
> >> >> >> At a point in my application I have to synchronize the time the
> >> >> >> internal
> >> >> >> clock, and therefore my application must have administrator rights.
> >> >> >>
> >> >> >> In. Net as you do it ? (to elevate your application to
> >> >> >> administrative
> >> >> >> level)
> >> >> >>
> >> >> >> Thanks
> >> >> >>
> >> >> >> Danilo
> >> >>
> >> >> >
> >>
> >> >
>
> >

Danilo, it is not a .NET thing, it is Vista thing. Under Vista applications
by default have minimum rights regardless of the logged-in user priviliges.
Application developer can elevate application rights to 'administrative' by
supplying <requestedExecutionLevel level="requireAdministrator"
uiAccess="false" /> in the application manifest security node. The effect
would be the same as launching the application 'AS ADMINISTRATOR'. This 'AS
ADMINISTRATOR' does not exist in XP. MS instructions on this matter tie this
entry to their infamous User Account Control
http://www.microsoft.com/downloads/t...displayLang=en
This can be somewhat misleading, because some users (most?) can have UAC
turned off, and the application still will not perform an administrative
task even if launched by an administrator. Embedding a manifest with an
entry elevating the application rights enables the application to perform an
administrative task. Below is a manifest generated by VS2008:
------------------------------------------
<?xml version="1.0" encoding="utf-8"?>
<asmv1:assembly manifestVersion="1.0"
xmlns="urn:schemas-microsoft-com:asm.v1"
xmlns:asmv1="urn:schemas-microsoft-com:asm.v1"
xmlns:asmv2="urn:schemas-microsoft-com:asm.v2"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<assemblyIdentity version="1.0.0.0" name="TrboServer.app"/>
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v2">
<security>
<requestedPrivileges xmlns="urn:schemas-microsoft-com:asm.v3">
<!-- UAC Manifest Options
If you want to change the Windows User Account Control level
replace the
requestedExecutionLevel node with one of the following.

<requestedExecutionLevel level="asInvoker" uiAccess="false" />
<requestedExecutionLevel level="requireAdministrator"
uiAccess="false" />
<requestedExecutionLevel level="highestAvailable" uiAccess="false"
/>

If you want to utilize File and Registry Virtualization for
backward
compatibility then delete the requestedExecutionLevel node.
-->
<requestedExecutionLevel level="requireAdministrator"
uiAccess="false" />
</requestedPrivileges>
</security>
</trustInfo>
</asmv1:assembly>
------------------------------

Michael

"Danilo Giuliani" <softdevo@tiscali.it> wrote in message
news:48c376f9$0$11368$5fc30a8@news.tiscali.it...
>
> "Michael Rubinstein" <mSPAM_REMOVE@m®ubinstein.com> ha scritto nel
> messaggio news:6ifob1FqhgscU1@mid.individual.net...
>> Danilo, I would try 'Run as administrator'. Ander Vista programs do not
>> inherit logged user rights. If running 'as administrator' works, then you
>> can change the manifest (if you supply one) to elevate your application
>> to administrative level. I never done this in VO, I do it for some of my
>> .NET applications.
>>
>> Michael
>>
>
> At a point in my application I have to synchronize the time the internal
> clock, and therefore my application must have administrator rights.
>
> In. Net as you do it ? (to elevate your application to administrative
> level)
>
> Thanks
>
> Danilo

A useful summary.
Thanks Michael.


"Michael Rubinstein" <mSPAM_REMOVE@m.ubinstein.com> wrote in message
news:6im6qlFre35sU1@mid.individual.net:

> Danilo, it is not a .NET thing, it is Vista thing. Under Vista applications
> by default have minimum rights regardless of the logged-in user priviliges.
> Application developer can elevate application rights to 'administrative' by
> supplying <requestedExecutionLevel level="requireAdministrator"
> uiAccess="false" /> in the application manifest security node. The effect
> would be the same as launching the application 'AS ADMINISTRATOR'. This 'AS
> ADMINISTRATOR' does not exist in XP. MS instructions on this matter tie this
> entry to their infamous User Account Control
> http://www.microsoft.com/downloads/t...displayLang=en
> This can be somewhat misleading, because some users (most?) can have UAC
> turned off, and the application still will not perform an administrative
> task even if launched by an administrator. Embedding a manifest with an
> entry elevating the application rights enables the application to perform an
> administrative task. Below is a manifest generated by VS2008:
> ------------------------------------------
> <?xml version="1.0" encoding="utf-8"?>
> <asmv1:assembly manifestVersion="1.0"
> xmlns="urn:schemas-microsoft-com:asm.v1"
> xmlns:asmv1="urn:schemas-microsoft-com:asm.v1"
> xmlns:asmv2="urn:schemas-microsoft-com:asm.v2"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
> <assemblyIdentity version="1.0.0.0" name="TrboServer.app"/>
> <trustInfo xmlns="urn:schemas-microsoft-com:asm.v2">
> <security>
> <requestedPrivileges xmlns="urn:schemas-microsoft-com:asm.v3">
> <!-- UAC Manifest Options
> If you want to change the Windows User Account Control level
> replace the
> requestedExecutionLevel node with one of the following.
>
> <requestedExecutionLevel level="asInvoker" uiAccess="false" />
> <requestedExecutionLevel level="requireAdministrator"
> uiAccess="false" />
> <requestedExecutionLevel level="highestAvailable" uiAccess="false"
> />
>
> If you want to utilize File and Registry Virtualization for
> backward
> compatibility then delete the requestedExecutionLevel node.
> -->
> <requestedExecutionLevel level="requireAdministrator"
> uiAccess="false" />
> </requestedPrivileges>
> </security>
> </trustInfo>
> </asmv1:assembly>
> ------------------------------
>
> Michael
>
> "Danilo Giuliani" <softdevo@tiscali.it> wrote in message
> news:48c376f9$0$11368$5fc30a8@news.tiscali.it...
>
> >
> > "Michael Rubinstein" <mSPAM_REMOVE@mRubinstein.com> ha scritto nel
> > messaggio news:6ifob1FqhgscU1@mid.individual.net...
>
> >> Danilo, I would try 'Run as administrator'. Ander Vista programs do not
> >> inherit logged user rights. If running 'as administrator' works, then you
> >> can change the manifest (if you supply one) to elevate your application
> >> to administrative level. I never done this in VO, I do it for some of my
> >> .NET applications.
> >>
> >> Michael
> >>
> >
>
> > At a point in my application I have to synchronize the time the internal
> > clock, and therefore my application must have administrator rights.
> >
> > In. Net as you do it ? (to elevate your application to administrative
> > level)
> >
> > Thanks
> >
> > Danilo

Geoff, my pleasure <g>. This subject is actually controversial. Personally I
find MS application privileges schema a handicap. It solves some security
problems only to create new ones. I have applications that perform
administrative tasks under certain circumstances. Some users may never need
my applications running 'AS ADMINISTRATOR', only those who plug in certain
hardware will need my applications to perform an administrative task like
network routing. I can't predict which user has and will use the hardware,
so I am forced to distribute these applications with
<requestedExecutionLevel level="requireAdministrator"...>. which really
beats the purpose of granting application minimally required privileges. In
my opinion these security instructions should be evaluated at run time,
rather then loaded from a resource (manifest) at application start.

Michael

"Geoff Schaller" <geoffx@softxwareobjectives.com.au> wrote in message
news:48c5eb68@dnews.tpgi.com.au...
>A useful summary.
> Thanks Michael.
>
>
> "Michael Rubinstein" <mSPAM_REMOVE@m.ubinstein.com> wrote in message
> news:6im6qlFre35sU1@mid.individual.net:
>
>> Danilo, it is not a .NET thing, it is Vista thing. Under Vista
>> applications
>> by default have minimum rights regardless of the logged-in user
>> priviliges.
>> Application developer can elevate application rights to 'administrative'
>> by
>> supplying <requestedExecutionLevel level="requireAdministrator"
>> uiAccess="false" /> in the application manifest security node. The effect
>> would be the same as launching the application 'AS ADMINISTRATOR'. This
>> 'AS
>> ADMINISTRATOR' does not exist in XP. MS instructions on this matter tie
>> this
>> entry to their infamous User Account Control
>> http://www.microsoft.com/downloads/t...displayLang=en
>> This can be somewhat misleading, because some users (most?) can have UAC
>> turned off, and the application still will not perform an administrative
>> task even if launched by an administrator. Embedding a manifest with an
>> entry elevating the application rights enables the application to perform
>> an
>> administrative task. Below is a manifest generated by VS2008:
>> ------------------------------------------
>> <?xml version="1.0" encoding="utf-8"?>
>> <asmv1:assembly manifestVersion="1.0"
>> xmlns="urn:schemas-microsoft-com:asm.v1"
>> xmlns:asmv1="urn:schemas-microsoft-com:asm.v1"
>> xmlns:asmv2="urn:schemas-microsoft-com:asm.v2"
>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
>> <assemblyIdentity version="1.0.0.0" name="TrboServer.app"/>
>> <trustInfo xmlns="urn:schemas-microsoft-com:asm.v2">
>> <security>
>> <requestedPrivileges xmlns="urn:schemas-microsoft-com:asm.v3">
>> <!-- UAC Manifest Options
>> If you want to change the Windows User Account Control level
>> replace the
>> requestedExecutionLevel node with one of the following.
>>
>> <requestedExecutionLevel level="asInvoker" uiAccess="false" />
>> <requestedExecutionLevel level="requireAdministrator"
>> uiAccess="false" />
>> <requestedExecutionLevel level="highestAvailable"
>> uiAccess="false"
>> />
>>
>> If you want to utilize File and Registry Virtualization for
>> backward
>> compatibility then delete the requestedExecutionLevel node.
>> -->
>> <requestedExecutionLevel level="requireAdministrator"
>> uiAccess="false" />
>> </requestedPrivileges>
>> </security>
>> </trustInfo>
>> </asmv1:assembly>
>> ------------------------------
>>
>> Michael
>>
>> "Danilo Giuliani" <softdevo@tiscali.it> wrote in message
>> news:48c376f9$0$11368$5fc30a8@news.tiscali.it...
>>
>> >
>> > "Michael Rubinstein" <mSPAM_REMOVE@mRubinstein.com> ha scritto nel
>> > messaggio news:6ifob1FqhgscU1@mid.individual.net...
>>
>> >> Danilo, I would try 'Run as administrator'. Ander Vista programs do
>> >> not
>> >> inherit logged user rights. If running 'as administrator' works, then
>> >> you
>> >> can change the manifest (if you supply one) to elevate your
>> >> application
>> >> to administrative level. I never done this in VO, I do it for some of
>> >> my
>> >> .NET applications.
>> >>
>> >> Michael
>> >>
>> >
>>
>> > At a point in my application I have to synchronize the time the
>> > internal
>> > clock, and therefore my application must have administrator rights.
>> >
>> > In. Net as you do it ? (to elevate your application to administrative
>> > level)
>> >
>> > Thanks
>> >
>> > Danilo
>

I don't disagree at all...

"Michael Rubinstein" <mSPAM_REMOVE@m.ubinstein.com> wrote in message
news:6im9tdFrbqroU1@mid.individual.net:

> Geoff, my pleasure <g>. This subject is actually controversial. Personally I
> find MS application privileges schema a handicap. It solves some security
> problems only to create new ones. I have applications that perform
> administrative tasks under certain circumstances. Some users may never need
> my applications running 'AS ADMINISTRATOR', only those who plug in certain
> hardware will need my applications to perform an administrative task like
> network routing. I can't predict which user has and will use the hardware,
> so I am forced to distribute these applications with
> <requestedExecutionLevel level="requireAdministrator"...>. which really
> beats the purpose of granting application minimally required privileges. In
> my opinion these security instructions should be evaluated at run time,
> rather then loaded from a resource (manifest) at application start.
>
> Michael
>

Geoff, Michael

I am amazed that in UK, most big companies in the construction sector
are sticking to XP SP2 - we still have a W2000 set of users - who have
fewest problems ... wonder what that tells us all ?

Even on new equipment !

Richard

Don't be.

It took big business 3 years to move over to XP from W2K. One of the
reasons is cost for effort return and many companies look at the
absolute cost, not the cost of security, maintenance and other things
which is lower with Vista. But the tide is turning. So much new stuff
(particularly in the virtualisation space) is Vista client only. A lot
of new security products are demanding Vista.

As it pervades the home (as it will), it will filter up into business as
people ask the question about why their corporate software is so far
behind what they have at home.

Geoff



"richard.townsendrose" <richard.townsendrose@googlemail.com> wrote in
message
news:578c1fb5-1f3a-4913-b46d-fe436e865941@s50g2000hsb.googlegroups.com:

> Geoff, Michael
>
> I am amazed that in UK, most big companies in the construction sector
> are sticking to XP SP2 - we still have a W2000 set of users - who have
> fewest problems ... wonder what that tells us all ?
>
> Even on new equipment !
>
> Richard