Lots of Vista info for qurious Windows users

GeoTrail · Post by **GeoTrail** » Mon Nov 27, 2006 2:41 am

I've been getting tons and tons of questions related to Windows Vista, specially about the licensing and different versions, which version is best for me and things like that. So I have found a very good article on PC World that should answer most of the questions that are floating around.

http://www.pcworld.com/article/id,12800 ... ticle.html

If there's something the article doesn't help you with, feel free to post your questions to me. I'm not a developer for Vista, nor do I have hardcore facts about the various drivers and such, but I know a few things about Vista from a user, admin and business standpoint.

Mike Stefanik · Post by **Mike Stefanik** » Wed Nov 29, 2006 3:19 am

For developers, the most significant thing to keep in mind is that Microsoft is only supporting Visual Studio 2005 under Vista. If you're using Visual Studio 2003, Visual Studio 6 or any other langauge, you're on your own. They've (sort of) made an exception for Visual Basic 6, but you have to run it in compatibility mode with administrative privileges, and desktop composition has to be disabled if you're using Aero. Microsoft's advice if you need to use an older version of Visual Studio is to stick with Windows XP.

Oh, and if you're distributing old-style WinHelp helpfiles with your software, you'll need to switch to HTMLHelp format. Vista doesn't includes the WinHelp viewer, and Microsoft has said that they're only going to make a version that's downloaded from them. (In other words, you're not permitted to package a WinHelp viewer in with your software or make it available for download from your website; you have to direct your users to download it from Microsoft directly).

srod · Post by **srod** » Wed Nov 29, 2006 1:41 pm

Does that mean that .chm will be deprecated?

gnozal · Post by **gnozal** » Wed Nov 29, 2006 1:59 pm

srod wrote:Does that mean that .chm will be deprecated?

No, .hlp files I think

GeoTrail · Post by **GeoTrail** » Wed Nov 29, 2006 8:23 pm

Correct, .hlp files, chm are compiled html files that are used in Vista. But you can still use hlp files in Vista if you download an add on.

oryaaaaa · Post by **oryaaaaa** » Sat Dec 02, 2006 9:01 pm

FrontPage - Windows Vista Wiki
http://windowsvista.ms/

For the driver who operates in kernel mode, the digital
signatures of Windows authentication are conditions.
When playing secure contents, this cannot be played unless
it fulfills conditions altogether.

I do not write a manual by CHM now.
It is because release of a block is needed.

utopiomania · Post by **utopiomania** » Sat Dec 02, 2006 11:01 pm

What I want to know about Vista, is simply how is it going to affect programs written in PureBasic

Do they work, or do users need to dive in somewhere and tweak security settings to make them work
out of the box??

I've seen some warning signs here about the webGadget under Vista, and any info on this and the above
will be appreciated!! Couldn't find it in the FAQ ?

GeoTrail · Post by **GeoTrail** » Sun Dec 03, 2006 2:51 am

I have tried allot of programs written in PB on Vista and haven't seen any problems yet. There might be issues later on with third party libs and external dll's not written specifically for Vista, but I haven't seen any of those yet.

utopiomania · Post by **utopiomania** » Sun Dec 03, 2006 8:19 pm

GeoTrail wrote:

I have tried allot of programs written in PB on Vista and haven't seen any problems yet.

Great!

So far so good.

Mike Stefanik · Post by **Mike Stefanik** » Sun Dec 03, 2006 9:32 pm

utopiomania wrote:What I want to know about Vista, is simply how is it going to affect programs written in PureBasic

The answer is "it depends". Under Vista, there's restrictions on what an application is normally permitted to do in terms of the registry and access to the file system. For example, attempting to create or modify keys under HKEY_LOCAL_MACHINE or write to INI files under C:\Program Files can get you into trouble.

Programs that will have problems will most commonly be those that make assumptions that they're running with Administrator privileges and have full access to the computer system. For example, let's say there's an application that reads some configuration data from HKEY_LOCAL_MACHINE. If that program opens the registry key with KEY_ALL_ACCESS, it's going to fail. Worse yet, it could be that the program assumes that the registry key will always exist and can be opened, so it doesn't do any error checking on the registry calls that it makes. That program is either going to fail unexpectedly, or it's going to use invalid or uninitialized data.

Microsoft has a whitepaper on UAC compatibility requirements for developers, which you can download from here:

http://www.microsoft.com/downloads/deta ... layLang=en

It's about 90 pages, but it's something that every Windows developer should read.

GeoTrail · Post by **GeoTrail** » Sun Dec 03, 2006 10:23 pm

I didn't know that Mike

I tried running this and all seems OK, the file creation of both the text file, ini and the registry key returns 1, but when I check, they aren't there.

Code: Select all

String$ = InputRequester("Enter a string", "Enter a string to be saved to a text file under Program Files:", "This is a string.")

If String$

	CreateFile(0, GetSpecialFolderLocation(38)+"Filename.txt")
	WriteString(0, String$)
	CloseFile(0)
	
	Delay(1000)
	If FileSize(GetSpecialFolderLocation(38)+"Filename.txt") = -1
	
		MessageRequester("Result", "The file couldn't be found at " + GetSpecialFolderLocation(38)+"Filename.txt" + Chr(10) + "That means the text file couldn't be written.")
	
	Else
	
		MessageRequester("Result", "The file was successfully written to " + GetSpecialFolderLocation(38)+"Filename.txt")
	
	EndIf
	
	If IniWrite(GetSpecialFolderLocation(38)+"Inifile.ini","Test section","Test key","Section value")
	
		MessageRequester("Result", "Successfully written an ini file "+GetSpecialFolderLocation(38)+"Inifile.ini")
	
	Else
	
		MessageRequester("Result", "Error while writing an ini file "+GetSpecialFolderLocation(38)+"Inifile.ini")
	
	EndIf
	
	If RegCreateKey("HKEY_LOCAL_MACHINE\SOFTWARE\Test",".") = 1 And RegSetValue("HKEY_LOCAL_MACHINE\SOFTWARE\Test","SZ Value","SZ",#REG_SZ,".") = 1
	
		MessageRequester("Result", "Successfully written a reg value to HKEY_LOCAL_MACHINE\SOFTWARE\Test")
	
	Else
	
		MessageRequester("Result", "Error while writting a reg value to HKEY_LOCAL_MACHINE\SOFTWARE\Test")
	
	EndIf

EndIf

srod · Post by **srod** » Mon Dec 04, 2006 1:13 am

I though that 'virtualisation' meant that such registry writes would succeed but would be 'redirected' to a part of the registry specific to the user currently logged into the system in a transparent way.

Maybe I should read a little more!

Mike Stefanik · Post by **Mike Stefanik** » Mon Dec 04, 2006 4:18 am

Registry and file virtualization only works under specific circumstances (for example, writing to a key under HKEY_LOCAL_MACHINE/Software) and it's something that Microsoft has included as a way to help with the transition.

Microsoft has made it very clear that virtualization of the registry and filesystem is something that you cannot depend on in future versions of Windows, and it can be disabled in Vista through group policy settings by the administrator. Developers are expected to change their code to conform to the UAC guidelines to ensure it runs correctly under Vista and future versions of Windows.

JCV · Post by **JCV** » Mon Dec 04, 2006 8:47 am

GeoTrail wrote:I have tried allot of programs written in PB on Vista and haven't seen any problems yet.

Are you using 32 bit or 64 bit vista?
No problem in compiling?

GeoTrail · Post by **GeoTrail** » Mon Dec 04, 2006 2:11 pm

JCV wrote:Are you using 32 bit or 64 bit vista?
No problem in compiling?

Im' running x86 right now. That is what I got my license for. My I have tried several RC versions of x64 and didn't see much difference between them. A few memory problems with programs not related to PB, but that might be because of errors in my memory chips. But nothing I can't live with hehehehe.