"The question you're asking appears subjective and is likely to be closed."
Yes this is a subjective question.
It has no answer.
I was just wondernig if I was the only one.
So... was it painful?
I just want to hear some comments.
Jag
P.S. Of course, it all depends on the app size, the language it was written, good or bad programming habits, etc...
Very painful, and a cost of several days if not weeks over time...
We had a lot of code revolving around sessions and IPC. So we were effected by the change of session 0 isolation.
For Vista x64 and 2008 x64 we also had some driver components that needed to be digitally signed with authenticode now. Which wasn't a requirement before.
We also ran into some trouble with some of our apps not having manifest files to specify that they needed to be run as an elevated process.
I had to move some registry keys from HKLM to HKCU - that was all - and I was very happy about that. About an hour or two. Less than a day form when it was discovered to when we had it fixed and in the source tree. Not sure of the line count on that C++ app.
Not huge, but not trivial
Not much. I worked primarily on a large app written in C++ and MFC. We moved to VS 2008 before Vista (waiting for VS 2008 SP1, which saved a lot of trouble), and most things just simply worked. There was one external library I found a slight problem with (compensating for old VC++ problems), but no big deal.
Except for a routine to grab a window and put it into JPEG format, which I narrowed down to a small stretch of standard code that was vetted by competent people both here and on the MSDN forum. Eventually, that problem went away on my computer, so I couldn't pursue it, but it has cropped up on others.
So, I never know when the goblins are going to come and take the JPEGs away, but other than that the transition to Vista was smooth.
Related
I maintain a lot of old VB6 code. The programs have been around a long time and run on many systems with no problems.
Recently we have been having strange, random problems with these programs on Server 2012.
I noticed that the project file referenced mscomctl.ocx#2.0 and a form file in the project referenced mscomctl.ocx#2.1.
Project file (vbp)
Object={831FDD16-0C5C-11D2-A9FC-0000F8754DA1}#2.0#0; MSCOMCTL.OCX
Form file (frm)
Object={831FDD16-0C5C-11D2-A9FC-0000F8754DA1}#2.1#0; MSCOMCTL.OCX
A process dump showed comctl32.dll was loaded twice
LoadedModule[39]=C:\Windows\WinSxS\x86_microsoft.windows.common-controls_6595b64144ccf1df_5.82.9200.17359_none_bf105a8645f47e85\COMCTL32.dll
...
LoadedModule[42]=C:\Windows\WinSxS\x86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.9200.17359_none_8935f06086091acc\comctl32.DLL
From what I could Google, it seems that comctl32.dll is a dependency of MSCOMCTL.OCX, which is also loaded.
LoadedModule[47]=C:\Windows\SYSTEM32\mscomctl.ocx
Is this cause for alarm?
Thanks for any help.
Your project (.VBP file) probably lacks the proper setting for Upgrade ActiveX Controls.
Open that file in a text editor and remove any line:
NoControlUpgrade=1
Or open the project in VB6 and check the box in the Project Properties dialog.
The answer is YES!
After I went through hundreds of programs and set them all to version 2.0 for MSCOMCTL.OCX and recompiled them, the problem stopped (Server 2012 caches applications so it took a while but it stopped).
FYI: Setting the NoConrolUpgrade=1 appears to be useless. The Kill bits for the OCX force VB6 to override the setting.
First, yes, you probably answered your own question.
MS has never been good with 'side by side' installs, and even the "Side by Side" implementation they came up with was bone dead. So my guess is that you are correct in assuming that two versions will cause problems. But that is just a guess based on experience.
Moreover, and not so much an answer to your question, but I'm with you on the maintaining older vb - regardless of some moronic comments that vb5/6 won't work on 'new windows', it still does (as long as you don't use a microsoft installer).
Like you, I now have to face reality and deal with a new learning curve. (upgrading loads of 'old' stuff). At least you have server 2012 running. I'm just coming to terms with that mess.
In delving into new code, and trying as best I can to put away notions of the stupidity of the syntax, I find I'm discovering new things that I like. And some that simply confound logical reasoning.
Since stack is not a forum for discussion, as was pointed out last time I got blocked, if you want to compare notes on getting up to speed, you can reach me at gjr!rockley.net
I'm sure you can fig that out.
Either Way, Good luck with it.
Gary
The process of compiling, creating exe and running it is very slow on my machine(and also stopping the exe by the stop button). Its a windows forms app with a very simple form. I see that in Release mode it works faster, but not fast enough.
There is also slow down of IDE right after I hit the stop button, it really needs to think about something for at least 10seconds(I understand that I'm killing the app, but why VS cant just understand it and don't think about it?).
Maybe uninstalling something or disabling something?
P.S. This is slow only after a few runs, but I think I just got too old machine. I would rather not update it right now.
I have 2GB of RAM.
I think the accepted solution is to upgrade to VS 2008.
Release mode will make the compiler slower, if anything. It generally makes the finished application smaller/faster, though.
VS2010 needs an enormous amount of memory, and if you have less than 3-4G, you're almost certainly being hit by that - that might be a cheaper upgrade than a new machine.
But all versions of the 'Visual' dev tools, right back to VC1.0, have been beasts that have required reasonably up-to-date computer specifications. I'm afraid that's just the way things are.
The BETA service pack worked wonders for me - lots of bits of VS2010 that were broken (like macros) started working and its significantly faster for me now - ymmv tho :)
Microsoft VS2010 SP1 Beta Link
This is a duplicate question, but I can't find the duplicate. So in summary here's what the other one said :)
1) Get more memory, 4gig as a minimum.
2) Disable extensions
3) A list of changes to speed things up 1
4) Might of found the original
I love all my extensions, so memory is key to me.
I saw that Beta 1 of VS2010 was publicly availible.
My question to those of you who has tried it is: does it work good?
Will it cause my computer to blow up in tiny pieces? Will it crash randomly? Will it work with some minor glitches? Or is it just perfect from bottom up?
I'm only coding school- and hobby-stuff, so nothing that someones life depend upon, but i still want software that works. How close to a final product is it? Is it worth trying?
It's a bit slow, and there's no offline MSDN, but it's worth trying IMO. Having said that it's slow, I still use it on my NC10 netbook, so it's clearly not that bad :)
I've got it side-by-side VS2008, and that hasn't caused any problems.
I've seen a couple of glitches (once the keyboard handling went completely wonky) but it's certainly usable. The main question is what you want to get out of trying it - in my case I absolutely need to code against C# 4 to explore the new features. I do most of that from the command line in fact, where the speed of VS obviously isn't an issue, but it's nice to see the VS-specific features as well (like the debug threading views for Parallel Extensions).
It seems more or less usable on the .NET side. The C++ side is a bit more sketchy. On one hand, they've added support for some very nice new C++0x features, on the other, they've broken some absolute fundamentals.
Your plain old main function won't compile in 32-bit with unicode enabled. (Workarounds: Either compile as 64-bit, disable unicode, or rename the function to wmain).
This seems to me to be a strong hint that the C++ side of things is nowhere near release-worthy. I'd probably wait for beta2 before doing any serious work with that.
I would say it is great, but the performance hurts a bit.
Here is an idea for you: Install it into a VirtualPC. Then you can play and not care what it does. You don't like it, delete the VPC image and keep on trucking. That is how I play with Microsoft betas now. I never install them on any real machine - too risky.
Usable: Yes.
Recommended: Not if you'r a touchpad-addict or dislike crashing apps.
I've been trying it for 2 weeks now coding small C#-projects and these are my impressions
Reasons to use 2010:
Looks good
Multi monitor support
I can see myself using the code templating but right now i couldnt find any really useful stuff except for reducing the fontsize of comments.
Zoom in the editor
Select a variable and then press shift+up/down to go to next usage of this variable
Ctrl+, brings up instant search of classes and functions in the entire project. (i've become really addicted to this)
Floating watches for single objects
Reasons to not use 2010:
TOUCHPAD SCROLL DOESN'T WORK IN THE EDITOR!!! (this is reason enough to not upgrade if you are using it on a laptop)
I've had some random app-crashes in the middle of just writing code, once or twice per day maybe.
UI sometimes freezes randomly for about 30seconds and then returns to normal.
It started to use 100% CPU power from one of my cores once when it was minimized in basic editing-mode and i was doing other stuff in other programs, i only noticed it because the fan started to go wild.
Otherwhise it's pretty similar to 2008. I haven't noticed any difference in speed like other people say.
You need to ask yourself: what is the advantage for you in using VS2010 over VS2008? I would suggest that there is no advantage if all you are doing is "school- and hobby-stuff".
I'm still using VS2008 for business related stuff (and, indeed, VC6 for some stuff). I prefer to wait until all the early adopters have tested it (and Microsoft has released at least one service pack after the real product release) before I do their testing for them.
It seems to co-exist with other versions of VS without causing any problems.
Regarding the slowness - it seems to be the UI that is slow, rather than building. Once it's going it doesn't seem much slower on my fast quadcore. I've yet to try it on my laptop.
It's usable enough, the small glitches that I've encounter weren't that bad. However, certain VS extensions(like XNA) don't work in VS2010 at the moment.
It's fun to toy with. Not usable for me, cause re#er does not support it yet (had to install TestDriven .NET which works through keyboard shortcuts only to run my tests).
Gave me an insight how addicted I am. :/
Btw, on Win7, without virtual pc it seemed even faster than vs2008 for me.
VS2010 doesn't yet support mobile device projects, which might or might not matter to you.
VC++ wise - VS2010 has a built-in 64-bit compiler, VS2008 does not.
You can supposedly add 64-bit support to VS2008, but it takes some effort.
I've been using VS 2010 beta (with .NET 4.0 beta) on Windows 7 RC. I've been trying to rewrite parts of a large-scale business application in it to see what can be done with it.
The UI freezes frequently. I'm talking 1-10 minutes between freezes. The UI does not come back, so I'm forced to kill devenv.exe every time it happens. Microsoft probably puts my error reports in their spam folder by now.
For me, VS 2010 beta 1 classifies as unusable. However, it's fast, the new IDE functions are very handy, and it's pretty. I keep coming back to it despite my resolutions to wait for a stable build.
Microsoft already has a Windows 7 Beta Customer Preview Program on their MSDN site where they encourage us to: "Evaluate and jump-start your development efforts on Windows 7 Beta".
Do you feel it is worthwhile to spend my time now re Windows 7, or should I wait a few releases, or even until after Windows 7 is released?
What are the advantages and disadvantages to starting this early?
As Paul said, there's absolutely no reason not to start now. What you fix now is something less to fix later - and you also get the benefit of having an application that is deployable on an OS that over 2.5m people are expected to download and install over the next few weeks.
Of course, you can expect to run the risk of having to make minor adjustments to your program as bug fixes are implement, or as new features are rolled out, but what you do now will still save you time - even if it just saves you having to become familiar with any platform-specific constraints further down the line, when pressures from potential clients, customers, etc. will be significantly higher.
I've installed windows 7 on two computer. So far, there has only been one small issue (the software did not find a USB device). I ran the compatibility wizard and now it works fine.
They have made it easy enough for a end user to take care of.
It's basically Vista 6.2. Lots of good improvements but not a new operating system. So it's no rush to test,
I've downloaded the Windows 7 beta and will be installing it into a VM shortly.
There's really no reason not to check your stuff on it now. It's way better for you to find and fix any problems before your users do.
Quite a few comments to answers in a different post, Where are the best locations to write an error log in Windows?, gave me the impression that a lot of things regarding standard folders (%APPDATA%; %TEMP%) in Windows Vista are different from Windows XP, which should of course be taken into account when developing software that will have to run under Windows at some point.
But in my company, I do not see that happen in this decade, and maybe not in the next either. I mean, the central IT deployed SP2 only eight months ago, and any question about SP3 is met with disregard (well, if you're lucky...)
So what is your advice? Should I rewrite two modules in my current project to make them ready for Windows Vista, or should I not bother about it at all, until it is really needed?
Make them Vista-ready, if only for the fact that Windows 7 will have the same changes. Better to future-proof now when you have the chance, than later when time is critical.
Personally, I'd have a quick look at the effort level of what it would take to enable "Vista Support" in your application.
If the effort levels are acceptable based on the allotted time to make changes in your project then it's good to account for the future in any design.
You know your implementation better than anyone!
We've had some issues in-house here with shortcuts and such as they were generated in an older installation suite. It's the little things that we are currently addressing in getting our Vista Support fully up and running. I'm sure there will be some "unforeseen" obstacles you will come across as well.
Best of luck!
The big thing for supporting Windows Vista in most desktop applications is to use references like your %APPDATA% rather than hard-coding paths. That should resolve any changed folder locations. And don't do anything that requires write access in your program's install folder.
Interestingly, these rules are true for Windows XP, too. It's just that in the past it was a lot easier to get away with breaking them.
There is no need to hurry. So far it is not critical, and who knows what next the version of Windows would look like.
Since you can't foresee an OS upgrade in the near future, don't worry too much about it. You should, however, keep the potential for an OS upgrade in mind whenever you're changing code. If anything is OS-specific in a section of code when you make changes, tweak it so that it is either OS-independent or easy to locate and modify later to make it OS-independent (depending on how long it would take to update it).
If you get into a situation where you're just tackling lesser issues, consider specifically aiming your fixes towards areas that you know (or suspect might) have code that would need to be adjusted if your company upgraded to Vista or Windows 7.
Don't bother, Windows 7 is coming out relatively soon, you'd be best off waiting to see what changes they make to support that! Last thing you want is to spend time fixing things for Vista..... and then fixing them all over again for Windows 7.
If you planning on upgrading your software for Windows Vista, check out Windows Logo Program, Requirements for the Windows Vista Logo Program for Software (Microsoft Word document, 183 KB, file name Windows Vista Software Logo Spec 1.1.doc).
Is your company going to upgrade to Windows Vista at all? A lot of companies are ignoring Windows Vista and are planning to upgrade to the next Windows version when it comes out in the hopes that it will suck less than Windows Vista. If this is the case, it would be a complete waste of time. Who knows what will change in the next version of Windows. It is better to rewrite once for the new Windows than to rewrite once for Windows Vista and then again for the next Windows version.