Vista question!

BlitzMax Forums/BlitzMax Programming/Vista question!

marksibly(Posted 2009) [#1]
Hi,

We're just in the process of deciding how to deal with some Vista admin issues, and would like some community input.

The problem is that Blitzmax needs to write to it's own directory, which Vista doesn't allow if you install BlitzMax to the "Program Files" directory unless you're running as admin.

Well, it sort of does - writes in non-admin mode go to a 'virtual directory' instead of 'program files'. But you're not allowed to write exes there which is nasty when compiling samples or 'untitled' tmp files.

The Windows-friendly solution would be to modify BlitzMax so that it writes data to a different directory, but that's a BIG JOB and wont be happening for a while yet (if ever).

So, we have come up with 2 other solutions:

1) Modify the MaxIDE manifest forcing MaxIDE to always run as admin. Pros: No need for user to do anything; Cons: User must always run MaxIDE as admin.

2) Add a check to MaxIDE to determine if it can successfully write to the appropriate directories (including writing a tmp .exe). Pros: User can potentially run MaxIDE in non-admin mode if installed outside of program files; Cons: User will have to manually select 'run as admin' if Max is installed to program files (same as current situation).

Personally, I prefer option 2, mainly because Max shouldn't really care if it's running as user or admin, just that it can write data where it needs to.

But what would Vista users prefer in general?


Gabriel(Posted 2009) [#2]
I agree with you. Option 2 is preferable.


Nate the Great(Posted 2009) [#3]
I vote option 2


seyhajin(Posted 2009) [#4]
Option 2 too


Tachyon(Posted 2009) [#5]
#2 is best I think. BlitzMax owners are not casual users- we are professional developers. I don't think it is asking too much to require us to give BlitzMax admin rights in order to function properly.


Htbaa(Posted 2009) [#6]
When installing it can't you just modify the read/write permissions? Its what I do after installing BlitzMax and BLIde as I don't want to run with UAC off.

So I'd say option 2.


Knotz(Posted 2009) [#7]
#2, I'm with Tachyon


QuickSilva(Posted 2009) [#8]
One thing that annoys me a little is that you have to give BlitzMax admin rights every time you run it if UAC is on. I have tried changing the read\write permissions but this still seems to be a problem, it asks me each time I run the program.

Also when UAC is on the IDE just displays a blank page (instead of the default help page) as I spoke of in the latest update thread. Not sure why this is happening either?

Jason.


GfK(Posted 2009) [#9]
How about option 3: Use the SHGetSpecialFolderLocation(CSIDL_LOCAL_APPDATA) API to get the correct app data path.

In vista this'd return C:\Users\marksibly\appdata\local. Create a Blitzmax subfolder in there and you're ready to go.

In XP you'd get C:\Documents and Settings\marksibly\Local Settings\Application Data.

This way you don't have to fanny about with admin rights.


GaryV(Posted 2009) [#10]
GfK: Why do things the right way?


joncom2000(Posted 2009) [#11]
I vote option 2, hate it when something wants to run as admin when it doesnt need to.

Perhaps a simple solution aimed as those people that never actually change the installers default location from program files is to make it point to something like "c:\blitzmax" or just have a warning that installing to program files will require running as admin on vista.


Murilo(Posted 2009) [#12]
GFK's solution appears to be the way forward (and the cleanest solution).

Having said that, I'm about to uninstall Vista and revert to XP. I hate Vista with a passion.


markcw(Posted 2009) [#13]
option 2 if, as you say, gfk's option 3 is too big a job.


sswift(Posted 2009) [#14]
GfK:
Is there a wrapper for that command in the code archives somewhere? There should be!

Also, is there an equivalent for Mac and Linux, or should I just continue to stick the data in the game directory on those?


GfK(Posted 2009) [#15]
I never put my version in the code archives, and I couldn't be arsed looking to see if anybody else had done it:
?Win32
Extern "win32"
	Function SHGetSpecialFolderLocation(hwndOwner, nFolder, pIdl:Byte  Ptr)
	Function SHGetPathFromIDList( pidList ,lpBuffer:Byte  Ptr)
End Extern
?

Const CSIDL_DESKTOP = $0
Const CSIDL_INTERNET = $1
Const CSIDL_PROGRAMS = $2
Const CSIDL_CONTROLS = $3
Const CSIDL_PRINTERS = $4
Const CSIDL_PERSONAL = $5
Const CSIDL_FAVORITES = $6
Const CSIDL_STARTUP = $7
Const CSIDL_RECENT = $8
Const CSIDL_SENDTO = $9
Const CSIDL_BITBUCKET = $A
Const CSIDL_STARTMENU = $B
Const CSIDL_DESKTOPDIRECTORY = $10
Const CSIDL_DRIVES = $11
Const CSIDL_NETWORK = $12
Const CSIDL_NETHOOD = $13
Const CSIDL_FONTS = $14
Const CSIDL_TEMPLATES = $15
Const CSIDL_COMMON_STARTMENU = $16
Const CSIDL_COMMON_PROGRAMS = $17
Const CSIDL_COMMON_STARTUP = $18
Const CSIDL_COMMON_DESKTOPDIRECTORY = $19
Const CSIDL_APPDATA = $1A
Const CSIDL_PRINTHOOD = $1B
Const CSIDL_LOCAL_APPDATA = $1C
Const CSIDL_ALTSTARTUP = $1D
Const CSIDL_COMMON_ALTSTARTUP = $1E
Const CSIDL_COMMON_FAVORITES = $1F
Const CSIDL_INTERNET_CACHE = $20
Const CSIDL_COOKIES = $21
Const CSIDL_HISTORY = $22
Const CSIDL_COMMON_APPDATA = $23

Function GetSpecialFolder:String(folder_id) 
	Local  idl:TBank = CreateBank(8) 
	Local  pathbank:TBank = CreateBank (260) 
	If SHGetSpecialFolderLocation(0,folder_id,BankBuf(idl)) = 0		
		SHGetPathFromIDList PeekInt( idl,0), BankBuf(pathbank)
		Return String.FromCString(pathbank.Buf()) + "\"
	EndIf
End Function


No idea about MacOS/Linux - sorry!


Brucey(Posted 2009) [#16]
I'm sure someone has a module for that somewhere...


sswift(Posted 2009) [#17]
GFK:
I think your code needs to be changed for it to work on Mac and Linux, as with the conditional compile, there'd be no SHGerSpecialFolderLocation() function when compiled on those systems.

But thanks for the code snippet. I think I'll modify it a bit and use that for storing my high score tables.


GaryV(Posted 2009) [#18]
there'd be no SHGerSpecialFolderLocation() function when compiled on those systems.
That is because Windows API calls are native to Windows :p


GfK(Posted 2009) [#19]
That is because Windows API calls are native to Windows :p

What he said ^^


*(Posted 2009) [#20]
I agree with GFK's version


Gabriel(Posted 2009) [#21]
I do what GFK suggests in my own game, but aren't you going to get some users complaining that they can't run Blitzmax when they're signed into their brother/mother/dog's account or something of that nature? Or worse, people complaining that BlitzMax is broken or their source code has been corrupted.

I think your code needs to be changed for it to work on Mac and Linux, as with the conditional compile

Since the problem Mark is trying to fix is only present on Windows Vista, I think it'll be ok ;)


*(Posted 2009) [#22]
I would do gfk's version or options 1, you would be suprised how many problems would come about with option 2 (also how many forum posts etc)


Gabriel(Posted 2009) [#23]
you would be suprised how many problems would come about with option 2 (also how many forum posts etc)

How can option 2 possible create any problems? It's the status quo except that some people currently affected won't be affected any more.


GfK(Posted 2009) [#24]
If it starts covertly writing EXEs every time you start the app, isn't it likely that antivirus/malware software will become the problem rather than UAC?


*(Posted 2009) [#25]

2) Add a check to MaxIDE to determine if it can successfully write to the appropriate directories (including writing a tmp .exe). Pros: User can potentially run MaxIDE in non-admin mode if installed outside of program files; Cons: User will have to manually select 'run as admin' if Max is installed to program files (same as current situation).


Well for one users have to manually set the run as admin option and that would have to be in the information available to all. Option 1 would sort the thing out completely after all programming stuff should be run as an admin anyways.

As gfk pointed out covert exe's being written all over the place would be a bit suspicious


sswift(Posted 2009) [#26]
What he said ^^


I am aware that those API calls only exist on Windows. That was the point of my post. Your code, as written, isn't cross platform.

Also, it doesn't make sense to have a compiler directive in code which is not intended to be compiled on Mac of Linux, and indeed, won't compile with the GetSpecialFolder() function you left out of the conditional portion there, because that function references those other functions that won't exist when compiling on platforms other than Windows.

Anyway, to fix this, I would reccomend the following:

?Win32
Extern "win32"
	Function SHGetSpecialFolderLocation(hwndOwner, nFolder, pIdl:Byte  Ptr)
	Function SHGetPathFromIDList( pidList ,lpBuffer:Byte  Ptr)
End Extern
?Not Win32
Function SHGetSpecialFolderLocation(hwndOwner, nFolder, pIdl:Byte  Ptr)
End Function

Function SHGetPathFromIDList( pidList ,lpBuffer:Byte  Ptr)
End Function
?

With suitable code in said functions, itself encased in ?MacOS and ?Linux conditional compiles, that return the expected results on those platforms, so as to work nicely with the GetSpecialFolder() function.


Gabriel(Posted 2009) [#27]
Well for one users have to manually set the run as admin option and that would have to be in the information available to all.

They already have to do that. That's what I meant when I said option 2 is the status quo.

If it starts covertly writing EXEs every time you start the app, isn't it likely that antivirus/malware software will become the problem rather than UAC?

What's covert about it? Besides, it's been doing it for two years, and it hasn't happened so far. I'm missing the logical leap which gets from "it's been ok for two years but terrible things will happen if it doesn't change now".


GaryV(Posted 2009) [#28]
Your code, as written, isn't cross platform.
He never claimed it was.


Mark Tiffany(Posted 2009) [#29]
He never claimed it was.

No he didn't. But if it is code only usable on win32, why have a ?win32 compiler directive? And by having a win32? compiler directive, it kind of implies it is intended to work cross-platform, but it won't compile on anything other than win32. sswift's additional ?not win32 section is all that is needed for it to make sense across all platforms.


GfK(Posted 2009) [#30]
[edit]

Actually, stuff it. Figure it out for yourself, Sswift. Gonna take a break from this place for a while before I end up saying something pretty soon that gets me banned.


Brucey(Posted 2009) [#31]
Getting exciting around here again !!! W00t!

I think I'll just stick with my working cross-platform module...

Thanks for the example GfK, much appreciated :-)


sswift(Posted 2009) [#32]
GFK:
What are you so upset about?


GaryV(Posted 2009) [#33]
And by having a win32? compiler directive, it kind of implies it is intended to work cross-platform,
Perhaps to a five-year old.


sswift(Posted 2009) [#34]
...


GaryV(Posted 2009) [#35]
sswift: Comment above was a reply to the quoted text which was not made by you. I am not sure how you imagine it as a slight against you?


*(Posted 2009) [#36]
make it run as an admin out of the box then theres no problems at all