Access denied on TPS

[NewsArchive]

Hi Friedrich,

I have a weird situation.

I have two demo programs. Identical except for installed exe etc.
Datafiles are put into CSIDL_LOCAL_APPDATA\Icetips Creative\Product
Name\Data

When I run the Magic Locks demo no problems. I can browse/update
files. When I run my Previewer demo, I get "Access denied, trying
read-only" on the tps file. Both apps use the same tps, but it's in
two separate folders. The ML demo is compiled local, the Previewer
demo is compiled standalone and DLLs are distributed.

Both exes have embedded manifests "asInvoker". Both are code signed.
Both installs require Administrator. I can't see what the difference
is... I'm running as administrator and the files are in the correct
place, C:\Users\Arnor... which is my admin account. The data is
there, I'm just getting this silly error message.

Any ideas?

Best regards,

Arnór Baldvinsson
Icetips Creative, Inc.
San Antonio, Texas, USA
www.icetips.com


Subscribe to information from Icetips.com:
http://www.icetips.com/subscribe.php

[NewsArchive]

If you want a second pair of eyes, post a link to the demos and I'll try
them on a Vista box.

Jane

[NewsArchive]

Hi Jane,

>If you want a second pair of eyes, post a link to the demos and I'll try
>them on a Vista box.

Thank you so much!

1. The Magic Locks demo - this seems to work without any issues:

http://www.icetips.com/downloadfile.php?FileID=74

This program installs without issues and I can browse and update the
data with no problems.

2. The Previewer demo. This one is the one that has problems. It
started out as a copy of the Magic Locks demo.

http://www.icetips.com/files/PreviewerDemo.exe

Install and run (Start | Programs | Icetips Creative |Demo | Previewer
Demo or something like that)

Click on the button furthest to the left in the toolbar to run the
first demo. On my vista machine when I'm logged in as admin, I get
"Access denied - Could not get write access, trying read-only" or
something like that. It points to the correct file, correct path etc.


When I compile the demo that I distribute with the Previwer and run
it, IT also complains about not getting write access. This doesn't
make sense to me.

I have a feeling that I must have forgot something in the install or
made a mess somewhere, but I'm darned if I can see it<g>

I'm out of town tomorrow and about to hit the sack so I may not get
around to reply until tomorrow evening.

Best regards,

Arnór Baldvinsson
Icetips Creative, Inc.
San Antonio, Texas, USA
www.icetips.com


Subscribe to information from Icetips.com:
http://www.icetips.com/subscribe.php

[NewsArchive]

>
> http://www.icetips.com/files/PreviewerDemo.exe
>
> Install and run (Start | Programs | Icetips Creative |Demo | Previewer
> Demo or something like that)
>
> Click on the button furthest to the left in the toolbar to run the
> first demo. On my vista machine when I'm logged in as admin, I get
> "Access denied - Could not get write access, trying read-only" or
> something like that. It points to the correct file, correct path etc.

Arnór,

Just installed it under Vista Ultimate - Administrator User account - and
tried all three reports - NO problems.

BTW, nice demo!

David


--
From David Troxell - Product Scope 32 PRO - Encourager Software
Clarion Third Party Profile Exchange Online
http://encouragersoftware.com/profile/clarlinks.html
http://www.encouragersoftware.com/
http://www.profileexchanges.com/blog/

[NewsArchive]

Hi Arnór,

> Install and run (Start | Programs | Icetips Creative |Demo | Previewer
> Demo or something like that)

Downloaded the installer (looks cool, btw <g>), installed it on three
different Vista Ultimate machines and started your Previewer Demo.

First of all, it looks very impressive :) The good news is that all three
reports work perfect here. No "access denied" or something like that.

Friedrich

--
Friedrich Linder
Lindersoft
www.lindersoft.com
+1.954.252.3910

"point. click. ship" - that's SetupBuilder 6.5
Create Windows Vista ready installations in minutes

-- Official Comodo Code Signing and SSL Certificate Partner

[NewsArchive]

Hi Arnor,

FWIW... You may want to consider changing the name of either the installer
exe or the actual program exe.

I attempted to install the demo into the same folder I downloaded the
installer into. When I tried to execute the demo after the install, much to
my surprise, I executed the installer again. The application exe did not
overwrite the installer exe.

Also, when the install completed the first time (the one that didn't work) I
received a notification from the installer that I needed to reboot the
computer. This did not happen after I changed the name of the install exe
and re-installed.

BTW - Nice work and timely for me. I have need of the RW interface right
now. Can't wait to put it to work.

--
Regards,

Lee
http://www.cya2day.com

[NewsArchive]

Lee,

> I attempted to install the demo into the same folder I downloaded the
> installer into. When I tried to execute the demo after the install, much
> to my surprise, I executed the installer again. The application exe did
> not overwrite the installer exe.
>
> Also, when the install completed the first time (the one that didn't work)
> I received a notification from the installer that I needed to reboot the
> computer. This did not happen after I changed the name of the install exe
> and re-installed.

Very interesting scenario <g>.

But you are right. If both the installer and application have the same name
(PreviewerDemo.exe) and if you install the demo into the same folder you
downloaded the installer into, then the installer is locked (in-use) and so
cannot install the application PreviewerDemo.exe. The installer asks for a
reboot (at the end of the installation) to "replace itself".

Friedrich

--
Friedrich Linder
Lindersoft
www.lindersoft.com
+1.954.252.3910

"point. click. ship" - that's SetupBuilder 6.5
Create Windows Vista ready installations in minutes

-- Official Comodo Code Signing and SSL Certificate Partner

[NewsArchive]

Hi Friedrich,

I have stumbled onto this several times with different demos.

I absolutely refuse to allow an unknown install, especially a demo, be
placed on my C: drive under Program Files. I have a special folder on
another drive where I install *all* demos. I create a sub folder for the
downloaded installer, download into it and then install the program into the
same folder.

When I'm done, hopefully, removing one folder gets rid of everything.

BUT... That's just me....<g>

--
Regards,

Lee
http://www.cya2day.com

[NewsArchive]

Hi Lee,

>FWIW... You may want to consider changing the name of either the installer
>exe or the actual program exe.

YES. I didn't realize it until I had uploaed the silly thing and was
testing it that it had the same name as the exe installed<bg> Too
many hours at the wheel<g>

>Also, when the install completed the first time (the one that didn't work) I
>received a notification from the installer that I needed to reboot the
>computer. This did not happen after I changed the name of the install exe
>and re-installed.

This happens if any of the files that were installed are in use, i.e.
for example if you have a file open or locked and run the install, it
apparently puts the files in a temp storage, requires a reboot and
finishes the file copying when windows starts again.

Best regards,

Arnór Baldvinsson
Icetips Creative, Inc.
San Antonio, Texas, USA
www.icetips.com


Subscribe to information from Icetips.com:
http://www.icetips.com/subscribe.php

[NewsArchive]

As others have said, Arnór, I also was unable to duplicate the failure you
describe (pic attached). I installed on both an Ultimate and a Home Premium
machine.

I did find one anomaly you might want to reconsider, although probably not
an issue with your product line.
I also ran the installation as a non-admin user, logged in as "Betty". This
required an "over-the-shoulder" admin account to permit the installation
program to run.

Unfortunately, presenting that administrator's credentials to UAC means the
demo data files were installed in that admin account's profile
(c:\users\jane\AppData\Local\yadayada) instead of in the user's
(c:\users\betty\AppData\yadayada). So when Betty runs the demo, the
cupboard is bare (pic attached).

If that's a real-world possibility for your customers, you might want to
consider using CSIDL_COMMON_DOCUMENTS for your non-individual sample data
instead.

Jane

[NewsArchive]

Jane,

> Unfortunately, presenting that administrator's credentials to UAC means
> the demo data files were installed in that admin account's profile
> (c:\users\jane\AppData\Local\yadayada) instead of in the user's
> (c:\users\betty\AppData\yadayada). So when Betty runs the demo, the
> cupboard is bare (pic attached).

Good one. It's a very important testing aspect. Quite often I forget to
test things with "over-the-shoulder" authentication :-( Rule Number 1 -
Stop thinking in XP, think in VISTA!

Friedrich

--
Friedrich Linder
Lindersoft
www.lindersoft.com
+1.954.252.3910

"point. click. ship" - that's SetupBuilder 6.5
Create Windows Vista ready installations in minutes

-- Official Comodo Code Signing and SSL Certificate Partner

[NewsArchive]

Hi Friedrich,

>Good one. It's a very important testing aspect. Quite often I forget to
>test things with "over-the-shoulder" authentication :-( Rule Number 1 -
>Stop thinking in XP, think in VISTA!

What does "over-the-shoulder" authentication mean?

I set up two user accounts on my Vista machine. One is admin account
and the other is regular user with standard access rights - i.e.
whatever defaults Vista gives you when you set up a non-admin account.
I test with both of them. My installs are set to
requireAdministrator, so when they run they require admin password.
My exes have manifests that are set to run asInvoker and are all
codesigned. My data goes into CSIDL_LOCAL_APPDATA. Note that ALL my
installs so far are either third party installs or third party demo
installs, so they are all going to developers who I would expect
generally would have admin rights on their computers. But the demos
should definitely work and install without any problems under a
minimal right access accounts. Am I missing something?

Best regards,

Arnór Baldvinsson
Icetips Creative, Inc.
San Antonio, Texas, USA
www.icetips.com


Subscribe to information from Icetips.com:
http://www.icetips.com/subscribe.php

[NewsArchive]

Hi Arnór,

>
> What does "over-the-shoulder" authentication mean?
>

Privilege elevation allows administrators to run the majority of their
applications at a safe privilege level, but also allow processes and
operations that require administrative privileges. The Vista UAC feature
supports "over-the-shoulder" (OTS) authentication (or aka "credentialing")
so that an Administrator can grant elevated privileges to a program while a
Standard User is currently logged onto the system.

Friedrich

--
Friedrich Linder
Lindersoft
www.lindersoft.com
+1.954.252.3910

"point. click. ship" - that's SetupBuilder 6.5
Create Windows Vista ready installations in minutes

-- Official Comodo Code Signing and SSL Certificate Partner

[NewsArchive]

Hi Friedrich,

>Privilege elevation allows administrators to run the majority of their
>applications at a safe privilege level, but also allow processes and
>operations that require administrative privileges. The Vista UAC feature
>supports "over-the-shoulder" (OTS) authentication (or aka "credentialing")
>so that an Administrator can grant elevated privileges to a program while a
>Standard User is currently logged onto the system.

Right - does that cause problems? How else CAN an installer that
installs programs install? A regular user without elevated rights
can't write to Program Files - or at least that is my experience. So
the installer must requireAdministrator in order to be allowed to
install under Program Files. If that causes problems with the
datafiles, then how can that be solved? And why would that work with
one install (magic locks demo) but not with the other (previewer
demo)??? The first one worked perfectly on my vista machine and
installed the files correctly and accessed them correctly (with exe
manifested asinvoker and when logged in with regular user account)

On my vista machine EVERYTHING that I have installed requires admin
password (elevation) to install when I install into the "regular user"
account.

Best regards,

Arnór Baldvinsson
Icetips Creative, Inc.
San Antonio, Texas, USA
www.icetips.com


Subscribe to information from Icetips.com:
http://www.icetips.com/subscribe.php

[NewsArchive]

Hi Friedrich,

>On my vista machine EVERYTHING that I have installed requires admin
>password (elevation) to install when I install into the "regular user"
>account.

What I meant to say that EVERY installer that I have used on this
machine has required admin password - not that the program require it,
just the installers.

Best regards,

Arnór Baldvinsson
Icetips Creative, Inc.
San Antonio, Texas, USA
www.icetips.com


Subscribe to information from Icetips.com:
http://www.icetips.com/subscribe.php

[NewsArchive]

Hi Arnór,

> What I meant to say that EVERY installer that I have used on this
> machine has required admin password - not that the program require it,
> just the installers.

If your installer requests administrator execution level, the user that is
running the setup (administrator in this case) is different from the user
that may use your application (JoeUser)! If you are a Standard User and you
start your installer, then over-the-shoulder credentialing kicks in. The
end result is that all data goes to the Admin account's profile! BTW,
during an "administrative setup" you should never modify HKEY_CURRENT_USER
(HKCU) and other per-user settings (e.g. writing to the user profile, etc.).

And do not automatically execute your application at the end of the
installation process (Jane posted a workaround some weeks ago). The problem
is that if you run that application at the end of the installation, it also
executes this app with administrator privileges. If your application does
some user specific initializations (as recommended by Microsoft), it will do
this for the Admin, not the Standard User!

So we have what Jane reported. If an application runs elevated (i.e. with
the user's full token), then data goes to Admin profile, not the User
profile.

Does this help?

Friedrich

--
Friedrich Linder
Lindersoft
www.lindersoft.com
+1.954.252.3910

"point. click. ship" - that's SetupBuilder 6.5
Create Windows Vista ready installations in minutes

-- Official Comodo Code Signing and SSL Certificate Partner

[NewsArchive]

Hi Friedrich,

>If your installer requests administrator execution level, the user that is
>running the setup (administrator in this case) is different from the user
>that may use your application (JoeUser)! If you are a Standard User and you
>start your installer, then over-the-shoulder credentialing kicks in. The
>end result is that all data goes to the Admin account's profile! BTW,

The HOW is a setup that actually WORKS on Vista supposed to be set up
in SB6.5? If I use execution level "asInvoker" the install can't
install into Program Files. If I use execution level
"requireAdministrator" it can't find the data files.

Best regards,

Arnór Baldvinsson
Icetips Creative, Inc.
San Antonio, Texas, USA
www.icetips.com


Subscribe to information from Icetips.com:
http://www.icetips.com/subscribe.php

[NewsArchive]

Hi Arnór,

> The HOW is a setup that actually WORKS on Vista supposed to be set up
> in SB6.5? If I use execution level "asInvoker" the install can't
> install into Program Files. If I use execution level
> "requireAdministrator" it can't find the data files.

I fear your Vista database location logic is "suboptimal" ;-) It's not
really an installation problem. Microsoft says that you have to handle all
user specific initializations (write to HKCU, etc.) at application runtime.
You cannot do this from within an elevated installer. And your installer
can only have "requireAdministrator" privileges - that means you can only
write to the Admin account's profile. For example:

c:\users\jane\AppData\Local\yadayada

You can *not* write (from the installer) to:

(c:\users\betty\AppData\yadayada). When Betty runs the demo
(c:\users\sue\AppData\yadayada). When Sue runs the demo
(c:\users\emily\AppData\yadayada). When Emily runs the demo

Your "asInvoker" application can only write to c:\users\sue\AppData\yadayada
when Sue is logged in. The installer cannot write to Sue because
administrator privileges belong to Jane.

But exactly the same problem would happen if you run your "asInvoker"
application "as administrator" ;-) IMO, yOu have to reconsider the location
of your database.

Does this help?

Friedrich

--
Friedrich Linder
Lindersoft
www.lindersoft.com
+1.954.252.3910

"point. click. ship" - that's SetupBuilder 6.5
Create Windows Vista ready installations in minutes

-- Official Comodo Code Signing and SSL Certificate Partner

[NewsArchive]

Hi Friedrich,

>But exactly the same problem would happen if you run your "asInvoker"
>application "as administrator" ;-) IMO, yOu have to reconsider the location
>of your database.
>
>Does this help?

No<g> This is all theory, I need practical examples. So I can't
write the data where it needs to go with the installer, I need to do
that with my program. Fine. WHERE do you I put the data that I
install so that my program can KNOW where to grab it and move it to
the appropriate location.

Best regards,

Arnór Baldvinsson
Icetips Creative, Inc.
San Antonio, Texas, USA
www.icetips.com


Subscribe to information from Icetips.com:
http://www.icetips.com/subscribe.php

[NewsArchive]

Hi Arnór,

>>Does this help?
>
> No<g> This is all theory, I need practical examples. So I can't
> write the data where it needs to go with the installer, I need to do
> that with my program. Fine. WHERE do you I put the data that I
> install so that my program can KNOW where to grab it and move it to
> the appropriate location.

No, not theory, it's Vista reality <g>. Running your own application "as
Invoker" or "as Administrator" will result in accessing **different**
profiles! And this is also not theory. Users can run YOUR "asInvoker"
application as Administrator under the "Standard User" account and your
application ends up accessing different profiles!!!!! The same app, the
same installation, different profiles. Do you see what I mean?

Please allow me to repost a previously mentioned interesting SetupBuilder
related thread from the Microsoft MSDN forum:

http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1213890&SiteID=1

So it's exactly what Jane said yesterday. You might want to consider using
CSIDL_COMMON_DOCUMENTS\YourAppName!

Does this help :)

Friedrich

--
Friedrich Linder
Lindersoft
www.lindersoft.com
+1.954.252.3910

"point. click. ship" - that's SetupBuilder 6.5
Create Windows Vista ready installations in minutes

-- Official Comodo Code Signing and SSL Certificate Partner

[NewsArchive]

Hi Friedrich,

>No, not theory, it's Vista reality <g>. Running your own application "as
>Invoker" or "as Administrator" will result in accessing **different**
>profiles! And this is also not theory. Users can run YOUR "asInvoker"
>application as Administrator under the "Standard User" account and your
>application ends up accessing different profiles!!!!! The same app, the
>same installation, different profiles. Do you see what I mean?

Yes, I know all this.

>So it's exactly what Jane said yesterday. You might want to consider using
>CSIDL_COMMON_DOCUMENTS\YourAppName!

But I don't want it COMMON, I want it LOCAL. THAT, my friend, is the
question:)

Best regards,

Arnór Baldvinsson
Icetips Creative, Inc.
San Antonio, Texas, USA
www.icetips.com


Subscribe to information from Icetips.com:
http://www.icetips.com/subscribe.php

[NewsArchive]

Arnór,

> But I don't want it COMMON, I want it LOCAL. THAT, my friend, is the
> question:)

Yes, I know. But you cannot copy from a "requireAdministrator" application
to a user specific (JoeUser) profile. Sorry for the bad news!

Friedrich

[NewsArchive]

By the way, and LOCAL is not LOCAL in Vista and Windows 2008.

I'll try it again. Your user starts your application under the Standard
User account. Let us assume you have LOCAL data available. Perfect, it
works! But now he starts your application with administrator execution
level privileges under the very same Standard User account. Oops! There is
no LOCAL data any longer! You are accessing another profile now. This
"over-the-shoulder" (OTS) credentialing is a new feature and a *permanent*
change to the Windows operating system!

Friedrich

[NewsArchive]

Hi Friedrich,

>You cannot do this from within an elevated installer. And your installer
>can only have "requireAdministrator" privileges - that means you can only
>write to the Admin account's profile. For example:
>
>c:\users\jane\AppData\Local\yadayada

Which the user does not have access to. If I log in as regular user
and try to access C:\Users\Arnor which is my admin username, I get
"You do not have permission to access this folder" So what good is it
to be able to write to the admin folder, when my program, running
asInvoker can not access it?

So, once again, in SB6.5 WHERE do I install datafiles for a program
that is manifested asInvoker so that my program can get to them and
copy them to the correct folder?

I'm really glad that I have methods in my utilities to create multiple
levels of directories with one call, and copy files from one folder to
another using SHFileOperations in one go<g>

Arghhhhhh!;)

Best regards,

Arnór Baldvinsson
Icetips Creative, Inc.
San Antonio, Texas, USA
www.icetips.com


Subscribe to information from Icetips.com:
http://www.icetips.com/subscribe.php

[NewsArchive]

Hi Friedrich,

>So we have what Jane reported. If an application runs elevated (i.e. with
>the user's full token), then data goes to Admin profile, not the User
>profile.

Yes, I have verified that that also happens in the Magic Locks demo as
I had not uninstalled my admin installation of it when I ran the
regular user install so it was reading it from the admin folder.

>Does this help?

No. The question remains and I have been over all the docs and
articles and I can not see the relationships here.

A non-elevated user can not install programs into Program Files where
they should be. An elevated user can install the programs, but not
the data.

How can an installer run asInvoker and get things into the proper
folders?

In your "Design Vista Applications and Installations with
SetupBuilder" topic, "Privileges During Installation" you state that
"Installing applications typically requires administrator privileges"

In your "Best practices", "2. Install applications and store per-user
data in different locations" you state the programs should go into
Program Files and data into C:\User\Username and registry keys under
HKCU. Agreed, but HOW do you do that?

How the heck is this supposed to be done so it is done properly and it
works for regular users, not administrators?

This needs a LOT more documentation in the help on actually how to do
it properly, not just the theories, but how to actually acomplish the
theory.

Best regards,

Arnór Baldvinsson
Icetips Creative, Inc.
San Antonio, Texas, USA
www.icetips.com


Subscribe to information from Icetips.com:
http://www.icetips.com/subscribe.php

[NewsArchive]

Hi Jane,

>As others have said, Arnór, I also was unable to duplicate the failure you
>describe (pic attached). I installed on both an Ultimate and a Home Premium
>machine.

Something was flaky on my machine last night and it would not allow me
to switch over to my "Regular user" account. I'll check this out in
the morning.

>Unfortunately, presenting that administrator's credentials to UAC means the
>demo data files were installed in that admin account's profile
>(c:\users\jane\AppData\Local\yadayada) instead of in the user's
>(c:\users\betty\AppData\yadayada). So when Betty runs the demo, the
>cupboard is bare (pic attached).

Was that in the Magic Locks demo or Previewer demo? I had tested the
Magic Locks demo under a user account that is NOT admin (regular user)
and it installed the files into the correct folder and worked without
problems on my Vista Home Premium machine. The Previewer demo I had
not tested as a Regular user, so I can't be sure if it was ok. I ran
into that silly access problem and wanted that figured out before I
did anything else.

Best regards,

Arnór Baldvinsson
Icetips Creative, Inc.
San Antonio, Texas, USA
www.icetips.com


Subscribe to information from Icetips.com:
http://www.icetips.com/subscribe.php

[NewsArchive]

Hi Jane,

>Unfortunately, presenting that administrator's credentials to UAC means the
>demo data files were installed in that admin account's profile
>(c:\users\jane\AppData\Local\yadayada) instead of in the user's
>(c:\users\betty\AppData\yadayada). So when Betty runs the demo, the
>cupboard is bare (pic attached).
>
>If that's a real-world possibility for your customers, you might want to
>consider using CSIDL_COMMON_DOCUMENTS for your non-individual sample data
>instead.

Well, they _should_ be individual. The installer has to run
requireAdmin or it can't install the program into Program Files.

Can you test the Magic Locks demo and see if _that install works
properly because that works perfectly on my Vista machine and put the
files in the right folder and no problems when I was logged in using
my "regular user" account.

I'll check this better in the morning. In my testing the data went
into C:\users\regular user\AppData\Local\... instead of
C:\users\Arnor\Appdata\Local\... (this is in the Magic Locks demo - I
hadn't tested the previwer demo with my regular user account since I
got that silly access problem when I was logged in as admin and wanted
to figure that out before I tested anything else)

Best regards,

Arnór Baldvinsson
Icetips Creative, Inc.
San Antonio, Texas, USA
www.icetips.com


Subscribe to information from Icetips.com:
http://www.icetips.com/subscribe.php

[NewsArchive]

Hi Friedrich,

>level privileges under the very same Standard User account. Oops! There is
>no LOCAL data any longer! You are accessing another profile now. This
>"over-the-shoulder" (OTS) credentialing is a new feature and a *permanent*
>change to the Windows operating system!

Yep, got all this:)

I don't have a problem with the UAC stuff. The problem was that I had
an install that I had installed on my vista in my admin account.
Worked perfectly as expected. I logged in as my Regular User and
installed. Worked perfectly. THAT was what threw me off as that
install should NOT have worked, but because stupid me I forgot to
UNINSTALL the program I installed under the admin account, the Regular
User installed program was reading the admin data and thus fooled me
into thinking that it had worked, when it actually hadn't. If I had
realized my mistake 10 days ago when I made it I would have realized
that my logic was wrong.

Best regards,

Arnór Baldvinsson
Icetips Creative, Inc.
San Antonio, Texas, USA
www.icetips.com


Subscribe to information from Icetips.com:
http://www.icetips.com/subscribe.php

[NewsArchive]

Hi Arnór,

> I don't have a problem with the UAC stuff. The problem was that I had
> an install that I had installed on my vista in my admin account.
> Worked perfectly as expected. I logged in as my Regular User and
> installed. Worked perfectly. THAT was what threw me off as that
> install should NOT have worked, but because stupid me I forgot to
> UNINSTALL the program I installed under the admin account, the Regular
> User installed program was reading the admin data and thus fooled me
> into thinking that it had worked, when it actually hadn't. If I had
> realized my mistake 10 days ago when I made it I would have realized
> that my logic was wrong.

Yes, I know what you mean :( I tested your product and did not notice the
problem. Jane found it immediately.

I have it in big letters on the office wall now. "Rule Number 1 - Stop
thinking in XP, think in VISTA!"

Friedrich