Jump to content

Recommended Posts

Posted

From I recent topic I discovered that SPTI does not work under limited user acounts on XP. What are the various advantages/disadvantages of each I/O interface, and which one(s) can be used under limited accounts ?

 

Has SPTI been chosen as the default simply because it's included on each OS version ?

Posted

SPTI allows the use of a bunch of other functions - like locking the volume so other programs don't interrupt the burn process, disabling MCN etc.

 

I've tried to implement some of them in the others where possible... sometimes the others have their own versions of said IOCTLs.

 

It will always default to SPTI under NT based OS's, and then ASPI under 9x. Yes, it does that because it's built in and so works for the vast majority of people.

 

I'm glad MS decided to allow device communication under Vista (as standard/limited user) via SPTI, it will make things much easier!

 

The other interfaces all need to be installed as an admin user, but after that they're available to any user. I guess that's the only benefit of them.

 

I use SPTI exclusively, so that's the one that undergoes all the testing.

That said, I never have reason to change the underlying I/O functions so there's no reason for anything to ever break.

Posted

I learned a new trick, YMMV, setup an admin account, install programs,

create a new admin account, change original to limited.

Enjoy

OT: been trying for a year to get certain programs to work this way with WinXP pro so our DJ's wouldn't hose the computer.

Posted

I guess I'll stick with SPTI then for reliability, although I prefer running in a limited account most of the time for security reasons unless installing apps or doing some general admin stuff.

 

Interesting trick chewy. I'll give that a try myself, although it tends to suggest there might be a problem with Windows if it's allowing access to certain parts of Windows which it shouldn't, when running under a limited account.

Posted

There's also a post in the FAQ about a possible workaround for the SPTI/Admin thing.

 

It worked for me once when I tried it.

 

I'm not sure chewy's idea is quite what we're talking about.

 

Surely that's just for the installation part, not the actual running of the apps? It would indeed be a massive bug in windows if you could change account types/permissions and yet still retain those of a previously applied security group!!!

 

As most apps probably work on a 'computer' basis rather than per user, I would think the general admin could have installed them and they'd work. If not, I'd say they weren't written very well - i.e. if they REALLY relied on something being there in HKCU.

 

For that kind of thing we'd tend to use group policy to push the apps out rather than having to install them manually. I guess it depends on how many machines you're working with though.

Posted

That's odd... it's quite a well known fact that SPTI is only available under and admin account.

 

SPTI gives you total access to write what you like to the hardware. So in theory, you could easily wipe a hdd or whatever - hence why it's Admin only!

 

That group policy option in the FAQ can get around it though.

You may also have some odd driver thing that's acting as a go-between and allowing you to bypass XP's security.

Posted (edited)
That's odd... it's quite a well known fact that SPTI is only available under and admin account.

 

SPTI gives you total access to write what you like to the hardware. So in theory, you could easily wipe a hdd or whatever - hence why it's Admin only!

 

That group policy option in the FAQ can get around it though.

You may also have some odd driver thing that's acting as a go-between and allowing you to bypass XP's security.

 

you are right, i have that group policy enabled, and i never knew about it or what it really was doing.

I must have played around with it, trying to maximize security. :D

 

BTW do you think that is a safe thing do.

Edited by dirio49
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.