Moved to Windows 7 (64) for development. What about UAC settings? [Windows Application] - security

For years Windows XP (32 bit)was my development desktop (personal projects). I develop many hobby projects and distribute it as open source and have never worried or bothered about checking it in Vista (I have used Vista only for a week). But none of my users have complained much about my apps in Vista.
Now I have moved to Windows 7 64 Bit OS (RTM). I am using Visual Studio 2008. I am developing an application which I am planing to sell.
I am using SQLite DB for data storage and everything went well until I decided to instal my first version in my laptop. Boom! app did not work as expected. I found that even though I was an admin user the app was not able to write to the DB (it said readonly).
Note: In windows 7 even if the logged in user has admin privileges, it prompts for confirmation if a process (sometimes even copy paste between drives) requires admin access. Not sure if this is new. Ignore if this is something old.
When I ran the app as "run as Administrator" it worked fine.
The app.manifest file has the following setting.
<requestedExecutionLevel level="asInvoker" uiAccess="false" />
I understand I can change it to either of the following
<requestedExecutionLevel level="asInvoker" uiAccess="false" />
<requestedExecutionLevel level="requireAdministrator" uiAccess="false" />
<requestedExecutionLevel level="highestAvailable" uiAccess="false" />
My question is if I change the setting to "requireAdministrator" will it affect normal users who dont have admin previleages?
How can I make my DB writable for a normal user?
How will this setting affect Windows XP users?
What is the best configuration which will let everyone update the DB without any issues?
This is the first time I am facing such an issue with security. Any advises?
Note: I will be testing this app in every possible OS. I ran a test in Vista 32 bit os (admin user) and it worked fine. But my experience with Windows 7 confused me.

Yes, normal users will have to supply administrator credentials.
Install your DB to a user writeable location or use a service / IPC to write to the DB for you.
Per-user database if possible. You can store the per-user stuff in user writable locations like AppData. If not, then using service/IPC to do the writes for you.

Your best bet is to install virtual machines with you're target OS's installed. You never really know what will happen until you test.

Related

Visual Source Safe 8 on Windows 2012

I have fairly large legacy (read only) VSS 8 database that is currently sitting on a windows 2003 server.
As part of an infrastructure consolidation I am being asked to move it onto a new Windows 2012 server. I can't find any notes on whether or not VSS8 will run on 2012; before I even attempt this do you know of any issues running VSS on Windows 2012?
Is it easier to flip the old server to a VM and keep it for posterity and those rare occasions we want to know what someone did in the naughties?
The database itself is merely a fileshare, so you don't have to install the accelerator if you don't want to/are unable to.
In the weeks since asking have deploying VSS2005 (with the runtime available on the server) onto Windows 2012 enterprise. The applications install with a warning about versions but they run fine; including the admin tools for users and checking the consistency of the databases. The end user side all works well too.

How to disable UAC programmatically to install a program by LE installshield for all users

I have an installation setup created by LE instalshield under VS2012. This setup.exe installs the application, registers some DLLs and activeX files and adds some registry entries as pointers to the location of an SQL server database. This application is to be run by all the users in a group policy created by the IT of their institution. The installation is done under the full administration privileges.
If the UAC of the win 7 is not fully lowered, some DLLs and OCXs are not registered (although the required registry keys are written in the MACHINE area of the registry without any problem!). So in order to avoid this I have to manually lower the UAC to its lowest level before running the Setup.exe. This solves the problem with the registration of DLLs.
But sometimes even though the installed program works for the installed login, it does not work for other logins within the same group/users. So how can I create a setup.exe under LEinstallshield that would 1) not require manual lowering of UAC, 2) install for all users under the same group policy?
Thank you for all your help.
You should be asking why your installer isn't compatible with UAC instead of asking how to disable UAC. If you are authoring a clean MSI using the registry tables (COM extraction) instead of using COM self-reg or other custom actions, it should just work.

Windows authentication in IIS 8

I am trying to setup RavenDB on my new Windows 8 dev machine. I have enabled Windows Authentication on that particular site and disabled Anonymous Authentication. I am logged in as a Local User account, which is also a member of Administrator. This normally works just fine on my previous Windows 7 dev machine. In this one I keep getting asked for login. I have tried using the account I'm logged in as but I keep getting asked to log in. I'm simply trying to use the RavenDB Studio.
I have tried this on Chrome and IE - probably missing something obvious/fundamental but can't think of what. Any ideas please? Thanks.
I was using unstable 1.2 build 2139. It was fixed in build 2140.

Converting Windows App written on XP to Windows 7

I inherited a huge code base which was written to work on Windows XP. Now we would like to migrate to Windows 7. I do not know what is the proper way to go about this. What is the proper approach to do the above task? I did some googling on differences between XP and Windows 7 but I do not get any proper links which describe how the internals of 7 differ from XP. Any links will be appreciated.
Usually how do S/W developers migrate their code/apps written for one version of OS say Vista to Windows 7?
I sell an autoupdate solution (AutoUpdate+, minor plug) and so have lots of experience porting Windows apps to the latest releases, and yet still maintaining backwards compatibility. Porting from Windows XP to Windows 7 can be a big challenge (there should be almost no difference in a move from Windows Vista to Window 7).
Window XP doesn't care where your application exists, and hence programmers would dump both their application and support logic (log files, config files, user profiles etc.) into the same location under "C:\Program Files\". Take this application to Windows 7 and you'll start finding some unusual behaviors. For starters, you will notice that files seem to 'disappear'. Instead of a log file being modified under the common Program Files location, you may end up with multiple, and separate, copies for each user under "Compatibility / Program Files". Windows Vista/7 introduced file system virtualization, and will now create separate user instances of files to ensure to ensure that each user has their own secure copy.
Another problem you will encounter on Windows Vista, and to a lesser extent on Windows 7, is User Account Control (UAC) prompts. It's similar to the issue above, in that new security restrictions will now cause Windows Vista/7 to prompt the user for approval to proceed. The most noticeable area where this occurs is when you are tampering with executable files in sensitive directories, installing applications and drivers, and sometimes when trying to self-update an app (the abovementioned app actually works around these prompts with some smart logic).
So in short, security changes are the biggest difference between Windows XP and Windows Vista/7. Your best start is to separate application logic (binaries) from supporting logic, by putting the latter into user specific directories. Some apps may never be fixable and can be forced instead to work in Compatibility Mode or to launch always under the Admin account context --- poor workarounds, but may be suitable in your company.
Simon # http://AutoUpdatePlus.com
There are three parts to the migration. First, make it just plain work. This means fixing up hardcoded file paths (there's no more Documents and Settings), changing some of your save locations so you don't need to be elevated to work properly and don't rely on virtualization, changing some of your registry key locations for the same reason, and coping with high-DPI which might now be applied automatically based on screen size rather than as a user's choice.
Second, make it look and work like a Windows 7 application. Is your jumplist usable? Your thumbnail? You get some things for free, do you like what you get or would you like to take control? Are there obvious wins you could use like thumbnail buttons, jumplist tasks, taskbar overlays, etc. Don't surprise your users and don't disappoint your users. (Example of disappointment: VS 2008 and the crummy jumplists it offered. They had the excuse of being released before Windows 7 - you don't.)
Third, take advantage of Windows 7 to be greater than you otherwise would. Stop polling for network joins, file creation, hardware being plugged in, going on and off AC power etc and learn how to get notified when those things happen. Add touch support beyond what you get for free. Talk to a sensor or GPS for the first time, since Windows 7 makes it simpler than it ever was. That sort of thing.
1 is not optional. 2 is really not optional either, a year after Windows 7 is released. 3 will differentiate you and I recommend, once you get past 1 and 2, you look into it.
Basically Windows7 is a 4bit OS and so necessarily runs on a 64bit processor environment. XP has 32bit as well as 4 bit flavours. If your application is for the 32bit version of XP, in that case, the major migration means making the application run on 4bit OS effectively.
The basic steps can be something like this:
Make it compatible to 64bit win7. So you may just compile the code off a win7 machine (on 64bit). If the compilation works fine, you might be able to run the app successfully.
The first step just allows to move ahead. But your application might not be effective. In that case, you might have to review the code for any specific implementation coupled on 32bit os and upgrade them to take advantage of 64bit OS.
The major advantages on 64bit OS is higher address-ability (so access more RAM) and also cache etc.
I did some googling on differences between XP and Windows 7 but I do not get any proper links which describe how the internals of 7 differ from XP. Any links will be appreciated.
API diff report between XP and Vista: https://abi-laboratory.pro/compatibility/Windows_5.0_to_Windows_6.0/x86_64/abi_compat_report.html
API diff report between Vista and 7: https://abi-laboratory.pro/compatibility/Windows_6.0_to_Windows_7.0/x86_64/abi_compat_report.html
The reports are generated by the abi-compliance-checker tool.

Any restrictions on development in Vista

I'm looking at a new computer which will probably have vista on it. But there are so many editions of vista; are there any weird restrictions on what you can run on the various editions? For instance you couldn't run IIS on Windows ME. Can you still run IIS on the home editions of vista?
Vista Home Basic only has enough IIS features to host WCF services and does not have any of web server features for hosting static files, asp.net, etc.
Here is a link to compare editions. I would recommend going with Home Premium or Ultimate depending on whether the computer will run on a domain.
You can't run Aero on the 'basic' editions, and there are some 'extras' that only run in Ultimate. You probably won't care about those for development, though. The only thing to be careful of would be that it has the same client access restrictions that XP did.
Get Home Premium unless you need to connect to a domain controller (if you don't know what that is, you don't need it).

Resources