Windows 7 question ( Starting new / old project )

I have an existing VB 6.0 project, fairly extensive probably 100k + lines of code. The project is an operating system for an XRF analyzer, multiple serial ports ( MS Comm ), a National Instruments I/O PCB, an MC I/O PCB, and some other custom hardware components. It also uses an OCX to automate another data processing program for spectral deconvolution. All written and working in WinXP Pro.

Now we are starting the process of a new instrument design, mostly the same hardware requirements. How much of a problem is it going to be if the new PC is Windows 7 Pro based ? ( 32 bit of course, I've been forewarned about that... ). they want to get away from the keyboard / monitor and instead use a touch screen I/F.

It should not be a problem but if it is there is an option.

If need you can go to Microsofts web site and download

Virtual PC
XP Mode

These are free to owners of Windows 7 Pro and Ultimate edition and when installed will allow you to run XP sp3 as a virtual machine under Windows 7

The downside of simulating the year 2001 for doing software development is that you will miss out entirely on doing most things that have changed in Windows since then. XP is not an ideal development environment.

Just to start with you won't have the ability to program and test using the features from the Tablet PC SDK, which covers several new controls that ship as part of Windows beginning with XP Tablet Edition and in all Editions beginning with Vista. The "XP Mode" VM does not support touch development.

There isn't any "XP Mode" feature for Windows before or after Windows 7 anyway. It's a bit of a dead horse.

The ideal VB6 development platform is actually Vista: the last OS officially supporting VB6 development. This will also save you the development instabilities in ADO and other things caused by Win7, Win7 SP1, etc. Of course Vista is nearing the end of its own support lifecycle now too.

See Windows XP Mode on Windows 8 Pro for much wailing and gnashing of teeth.

XP mode has its uses :) some older software that may still need to be supported and will not work under windows 7 can be used there without any issues at all. I have one product that I still have to support that was written in VB5 and VC++ 2.5 under Windows NT 4.0 the last major update to it rebuilt the project in VB6 under Windows 2000. The product works great under Win NT, 2K and most XP systems. It will not work under Windows 7 so If a customer upgrades to Windows 7 the only way they can continue using the software that we have found is to use XP mode which happily none have complained about so far :) The company has decided a long time back not to do any updates to the software and just let it run as long as it can. 13 years since the last version was released....

True enough, and that's what XP Mode was for (running non-conformant legacy applications).

But the OP is asking about doing development.

And keep in mind that you can still scrounge up an XP license and install it under a supported VM system on a Win8 machine. You just can't use a free Win7 "XP Mode" VHD.

Maybe what I want to do isn't totally clear. I want to add more features and functions to this already existing program which is quite large. I believe I can install the VB 6.0 development system on Win7, and then start coding new features and then compile a new even larger and more complex version of this program.

Do I absolutely HAVE TO use the XP virtual mode for Win7 when I do this ? It sounds like some of you are saying yes to this question ?

And it sounds like I won't get touch screen functionality if I DO use XP Mode on Win 7, is that correct ? But if I use Win7 non-XP mode I WILL get Touch Screen functionality ?

I'm not going to ask anything about Win8, I read a while on that link, scary stuff...

I have no problem developing on a Windows 7 system. (Don't know how it is under a 64-bit version of it to be honest)
The only downside is that the IDE is slow. But you can fix that really quick when you go to the compatibily tab of the VB6.exe and check the "Disable desktop composition".
And the problem with the UAC can also be fixed. See my thread http://www.vbforums.com/showthread.p...ues&highlight=

Quote:

---

Originally Posted by Krool

The only downside is that the IDE is slow.

---

This is probably a description of sluggish Form design window drag operations and such while Aero is enabled. You can just set this to disabled on VB6.EXE via the appcompat Properties of the EXE. You can also set "Run as admin" here, which you need to do anyway (there is no mystery about UAC, development always requires elevation to avoid a quagmire).

XP has no support for the standard Windows "touch" APIs (at least not until Tablet Edition, which is not available for general installation in a VM anyway).

Just use Win7, forget "XP Mode."

Of course you might consider that some "touch screens" and digitizer-style devices present themselves as multi-touch mouse devices. Those may come with custom drivers and XP versions might be supplied by your vendor.

All bets are off on those... I have no clue how they look to VB except as a regular mouse.

Quote:

---

Originally Posted by dilettante

You can also set "Run as admin" here, which you need to do anyway (there is no mystery about UAC, development always requires elevation to avoid a quagmire).

---

If you try to open a .vbp project file than the "Run as admin" method to the VB6.exe dont work. With the method to implement the "RequireAdmin" in the resource of the VB6.exe works instead. So there is a issue with the UAC.

When UAC came out back in 2006 Microsoft told developers that IDEs must always be run elevated.

Even on XP you need to be an Administrators or Power Users user for everything to work correctly. So effectively there is no change except that UAC prevents unsafe operations without user action to accept the prompt, and the unsafe Power Users group was removed.

It is 2013, there is no reason to make a fuss about something we're all supposed to know.

I just wanted to say that the IDE needs full admin rights in order to start.
And that was for example a trouble for me at first when I switched to Windows 7 as I am used to start the projects via the .vbp shortcut.
Of course if somebody disable the UAC all problems are gone. I just wanted to describe a solution to get it to work without to disable the UAC.
Thats all.

Quote:

---

Originally Posted by prginocx

Do I absolutely HAVE TO use the XP virtual mode for Win7 when I do this ? It sounds like some of you are saying yes to this question ?

---

The answer would be no in almost all cases. I do have a couple of old projects here that will not run under Windows 7 due to the fact that they were originally written to use some 16 bit sub system calls that really should not even be there and will not run under Windows 7, in fact they will not run on some XP systems where the 16 bit subsystem has been disabled. The projects are old and not worth changing so customers who still use them under windows 7 have to use XP mode and of course XP mode does work pretty well under windows 7 and is suitable for much design work. Also there is the added benifit of being able to make a copy of the resulting VHD to be able to get the development environment runnign on another PC with ease should your system ever crap out.

For the most part VB6 is fine under windows 7. You just have to install as admin then set the shortcut to run as admin and install sp6 also as admin.

I did run into trouble trying to install VB6 from the VS6 Pro CD something related to the Java VM. The stand alone VB disks worked without issue.

As for the IDE being slow I am totally unaware of this. I have VB6 on a windows XP box, a windows 7 box and a windows 8 box and the IDE is very snappy on all of them. I really haven't noticed any difference. Of course all of these systems have way more ram than needed for what they are doing and not a lot of extra processes running that are not needed.

Getting the VB6 development environment working is a trivial enough matter. I suspect the bigger issue is the other part that has been ignored by most posts here: the touch screen issue.

Doing that part may work just fine if the touch screen "looks like" something that VB6 can talk to. If it uses a custom API then even XP may be fine for development, assuming you can put the beast on an XP machine.

The downside of XP development is you lose access to newer APIs including some standard ones for tablets and you may be led to break development rules that XP will let slide under Win9x appcompat.

Without specific information about the proposed "touch screen" there isn't much more we can add though.

I guess it depends on the screen and how it works. I do know that I have been doing development for touch screens for over 10 years now and have never had an issue. I have not however worked with the newest devices that let you slide and resize things by dragging you fingers. Pretty much all of the touch screen devices I have came into contact with the touch just looked like a mouse click or mouse move. I even had one old touch screen CRT that I used under Windows 95 and VB4 :)

Well, that is a much more complete answer. You'all will be happy know it seems everyone agrees with the tech support (sales) person at the industrial PC shop (SupeLogics) where we get our host computers....

He seemed confident the touch screen on their modular touch screen PC would work with my program no matter what OS they ship. He also said it is extremely common for clients to order units with Win7 PAID FOR, but they downgrade to XP Pro and ship as such...You get the Win7 CD with the unit. So there are still a ton of XP users out there ordering expensive brand new industrial PCs...

Thanks a lot for all the expertise !