I have some free-standing C++ code (i.e. not a Windows program) that needs to identify the version of Windows that is installed on a PC.
I can easily differentiate between the different Windows client releases by kernel version (e.g. GetFileVersionInfo on ntoskrnl.exe), however I'm wondering if there's a reliable way to distinguish between a client and server installation.
A problem arises when using this method to distinguish between Windows Vista SP2 and Windows Server 2008 SP2 (6.0 build 6002 the both of them) and Windows 7 and Windows Server 2008 R2 (6.1 build 7600 for RTM and 6.1 build 7601 for SP2, both). What is a reliable (and preferably as straight forward as possible, avoiding the registry would be great as access to Win32 API is not available) method of identifying client vs server OSes correctly for code running outside the environment?
I suppose I could check for files only present on the server edition (what's a good file guaranteed to be on any server edition install, regardless of configuration?), check the Panther folder (which is safe to delete, so no guarantees there), etc. but I'm sure this is a problem that people have run into before and (hopefully) solved more elegantly?
(Sidenote: this question has been asked on SO before, but the solution (WMI) is inapplicable for out-of-band checking)
I'm not entirely sure what you mean about out of band checking, so I'm going to ignore that for the moment.
The normal way would be to call GetVersionEx, and look at the wProductType member of the OSVERSIONINFOEX.
A PE image does NOT specify whether the image should work on a client or server. It only specifies the runtime requirements regarding subsystem, dependencies, memory, affinity, etc...
I ended up searching for a number of binaries in the system32 directory that are generally associated with the Server Edition of Windows. It's not very clean, but in practice it works very well.
Related
I would like to know if Informatica can be used on Windows system ? If so what are the prerequisites?
Both the previous answers are wrong.
Windows 10 is supported for installing the client tools only.
For exact details which Windows server versions are supported, please log on (after initial sign-up if you haven't already done so) to the Informatica Network at https://network.informatica.com ; there's a section named Product Availability Matrices, here you find for each PowerCenter version the so-called Product Availability Matrix (PAM) indicating which Windows versions are supported for server installation and for client installation. You need both, and you can install both on the same Windows server system.
I won't go into this ugly ancient flame war here. Be it enough to say that some people managed to install the server part on Windows 10, but very few ever made it work reliably (in most cases the installation seems to work but doesn't, at latest after the next system restart). I wouldn't waste one single second trying to do so, it's not worth the time.
I'm using PDFCreator to create PDFs in VB6. My VB6 development VM is Windows XP 32-bit. On that system PDF generation works both from a desktop app and from ASP (via VB web class runtime).
When I create an exe to run on Windows 7 or Windows Server 2008 R2 or use it in the web class runtime I get:
Run-time error '429':
ActiveX component can't create object
This is when using early binding. I add a project reference to "C:\Program Files\PDFCreator\PDFCreator.exe" and then in my code I do:
Public WithEvents mPDFCreator As PDFCreator.clsPDFCreator
Set mPDFCreator = New PDFCreator.clsPDFCreator
If I don't use a project references and use late binding instead, then it works on the desktop app but still not in the web class runtime. Late binding is done like so:
Set mPDFCreator = CreateObject("PDFCreator.clsPDFCreator")
I want to use early binding so that I can use the events, plus I need it to work in ASP/Web Class Runtime.
I realise I'm dealing with ancient technologies here and I should have tempered expectations when running such things on modern 64-bit Windows and IIS. If porting this legacy app to .NET were an option, I would.
On IIS I have set the Enable 32-bit Applications setting on my app pool. I have also tried running it as Administrator to rule-out security problems.
I've done everything I know how to debug this, but I'm stumped. I suspect it has something to do with PDFCreator being a 32-bit app and COM registration. I've also tried running regsvr32 out of SYSWOW64 but PDFCreator.exe can't be registered.
Windows 64-bit architecture does not allow the load of 32-bit dll into 64-bit processes.
But you can modify the configuration of your vb project to convert it from an in-process dll COM component into an out-of-process exe COM server. This will allow you to instantiate your 32-bit component from a 64-bit process.
See Process Interoperability
Since this is a VB6 question there aren't any 64-bit processes to worry about.
It seems far more likely than anything else that this library just isn't being registered properly. I haven't use it since I don't know whether its setup works properly. I do know that the download itself does not display with a UAC Shield on its icon, suspicious in itself. For all I know the setup program spawns a run of the wrong regsvr32.exe.
But it seems more likely you have misregistered the library manually after copying it naked over to these 64-bit Win7/Server 2008 systems.
In any case, going over all of the symptoms you describe, I'd guess it got registered as a 32-bit ActiveX library but registered in the per-user virtualized part of the registry for the user you were logged on as when you registered it.
This can be a hassle to clean up after. However you should, and then be sure to manually run the original setup once again with elevation.
These threads that include hand-wringing over "ancient technologies" really get old. It's a poor workman who blames his tools. In the future why not hire an experienced programmer to handle tasks like this?
I use PDFCreator in my accounting software written in VB6. Years ago, I noticed that after a certain update from the makers of PDFCreator, my software stopped working properly with it. The problem stopped after I re-installed the older version, and came back when yet another new update was released from them, so I have had my customers freeze at the version that worked. I don't know off the top of my head what version that was, but I can check my own web site since I made it downloadable for my customers if it would help, but it's likely many years old now.
VisualSVN server is a nice piece of software; particularly in that it uses the builtin Windows authentication mechanism on my server. I'd like to try to start using Mercurial though, and I'd like to keep the Windows authentication scheme.
Is there some way to set this kind of thing up using the tools available on Windows Server 2008 R2 Standard (in particular, IIS 7)?
If you're using it within a LAN, you can just store your mercurial repo on a windows network share - no need for a server component.
If need it web-accessible, the answer Am linked to above seems to cover how to set up IIS.
If you're not adverse to paying, Kiln might be worth investigating, though I can't tell from the info on the site if they use Windows auth.
Excuse my necroposting, but I've just released an alpha version of HgLab, which is a purely managed Mercurial Server for Windows.
so far i have winsrv 2003 as the operating system on my dev-machine. now my manager asks me if i can switch to win7 because of licencing costs.
anybody of you know any good reasons for doing/not doing this?
I've been using Windows XP on my dev-machine at work, without any problem -- Linux would have been just as fine (or more) too.
I don't see why Windows 7 wouldn't be OK for a development machine, as long as you have all the drivers you need -- you probably don't need a server environment to develop, do you ?
Of course, I wouldn't say the same for a testing/staging server, which has to be as close as possible to the production one.
We don't know what you're developing, but I don't recall ever being hampered by not developing on a server-grade OS, apart from debugging OS-specific issues (which will always happen whatever you pick).
I've been running my dev environment on Windows 7 since the RTM hit. Developing with Visual Studio 2008, SQL 2008, Visual Basic 6, running VMWare--all with no problems.
I'd say the best reason for doing it is because your manager has asked you to.
Seriously, if the company has decided that's the way it want's to go, in my experience you don't usually have a lot of choice.
I have decided to go with Subversion for a source control repository for my personal and side projects and I'm now trying to decide what OS to use. Currently my file server for my home network is Windows 7 beta. I'm wondering if I should wipe it and install Windows Server 2008 instead? Basically I'd like to know if there are things I could take advantage with a server OS that I can't with Windows 7. First thing that comes to mind is accessing subversion remotely with a VPN connection.
I'm a .net developer, but have dabbled in Linux a bit so I'm not completely turned off to the idea of an ubuntu or debian server...
I imagine the installation and configuration process might go off with fewer hitches if installed on Linux, just because of the package management, but that's assuming some experience with the package system of $whatever_distro. If you're comfortable with Windows, Subversion works perfectly well on there. I've set it up on both, but prefer the Linux installation process (easier Apache integration, in my view), but I had pre-existing Linux experience.
If you're familiar with Windows, I bet you'll find the installation and configuration process easier there. As others have said, many of the tools are cross-platform.
You can run a Subversion server on Windows or Linux (or whatever) so it really doesn't matter. Pick whichever one you already have and feel most comfortable with. Since you are a Windows developer I see no real reason to toss Linux into the mix though.
If your goal is to minimize the amount of work you put into the maintenance of subversion, go with the OS you are most comfortable with. Many maintenance scripts, and subversion hooks are written and available in perl and python which are available for both windows and linux.
One advantage to the Windows server OSes over their client counterparts is that the client OSes are limited as to the number of inbound connections. If you are going to be the only person working on the repo, this may not make a difference. However, if there are multiple people, then this would be an issue. XP Pro/Vista Ultimate are limited by Microsoft to 10 inbound connections. I cannot speak for Windows 7.
To make life easy, try VisualSVN Server. For personal projects there's no reason to setup a separate server just for SVN.
Windows 7 will be able to host Subversion with no problems whatsoever..
If your file-server is already setup and working under Windows 7, I'd say stick with that.. Adding SVN is no reason to install a new OS
You don't need a server at all to use subversion.
If you've already got a file server on your home network, and you're doing this only for you and your personal projects, just use a subversion client such as TortoiseSVN and create your repository (or repositories) on your file server via network share (or mapped network drive, etc).
I wouldn't recommend this for multi-user setups (unless each has their own repository), but for a single user this is the simplest option. And using this approach, to answer your question, you wouldn't gain anything by switching to a server OS such as Windows Server 2008.
I'd actually recommend going with a hosted Subversion provider instead of setting up Subversion on Windows or getting a second server for that purpose. I work for ProjectLocker, but if you Google "subversion hosting", you'll see there are a number of providers that offer free or reasonably priced solutions. The advantages:
It's a hosting provider's primary job to keep your code safe, secure, and accessible, so they focus on uptime, backups, and security monitoring so you don't have to
You don't have to learn how to be a system administrator or Subversion administrator; several providers have user interfaces that make it easy to manage users and permissions.
Hosting instead of DIY lets you focus on what you actually care about: writing great software
I suggest you take a look at ProjectLocker and some of the other providers and decide which one is right for you. You may decide that doing it yourself is the best option for you, but for many people in your situation, a hosted solution has met their needs.