Quite often when there are many other applications running, Tortoise SVN's unified diff viewer can fail to show up - with a quick splash and then disappears immediately. But after closed some other applications, this diff viewer might act normally again. I suspect this is related to the available GDI resources left in system, according to my observation, though in fact any other applications (even heavy resource consumers like MSWord/Excel...) can start without problem.
Has anyone got any idea of solving this?
OS: Windows XP SP3
TortoiseSVN 1.6.16
Tried use TortoiseUDiff.exe from TortoiseSVN 1.7.10 and problem solved. Seems should be bug in 1.6.16.
Related
the problem I'll be describing might be caused by different reasons:
on linux opensuse leap 15.1 gnome (wayland) I can share e.g. mupdf but not evince or libreoffice in chromium jitsi session with screen share application window
another participant on windows tried to share a pdf document using microsoft office 365 and it seemed to show on his browser, but not on the other conference participants' browsers (one chromium on linux as in 1., the other firefox on windows), so he could not share his screen
I could not find any information on this topic using search machines. So I would appreciate if there is any answer on this out there in the community.
Looking forward to solving this ...
Cheers
JFM
PS: on the setup described in 1. also obs studio fails to screencast, maybe there is something related to this system setup causing this problem, some video driver setting e.g.?
This is probably related to Wayland, which has more restrictions than classic Gnome. Since you are having the same issue with OBS this sounds like this a classic Wayland permission issue.
I know they are working on implementing screen sharing support via pipewire but no idea how far this is.
You might try to switch back to Gnome on the X-Server until this is properly implemented.
I have been having problems with my Windows 10 (for example my localhost:8000). So I started looking for an answer, and it looks like the good old IIS is causing this issue, maybe because it's not enable in the turn Windows features on/off. SO in theory it should be a piece of cake right? Well when I click next I get the following message:
Windows couldn't complete the requested changes.
The function attempted to use a name that is reserved for use by another transaction. Error code: 0x80071A90
I read somewhere that it may be related to the .NET Framework, I have Framework 3.5 and 4.6 installed. I have tried all possible combinations, enable both of them, disable both, only one, everything! Not real information around regarding the Error code either.
Does it have something to do with the version of Windows that I have? Which is Windows Home. Is there any other way to make it work? Thank you in advance for your input.
As this is one of the first hits when you search for that error message posting solution here...
If you get this error when trying to "Turn Windows features on or off" in Windows 10 - make sure to disable Antivirus program.
Culprit for me was Avast.
To disable Avast right click on the icon in task-bar -> Avast shields control -> Disable until computer is restarted.
After Avast was disabled I had no problems with adding new features.
I have successfully used the WPRUI and WPA applications in the past, the last time a month ago, to identify performance problems in our C++ applications. But today I recorded a new trace of one of them, and open it just to see WPA crashing.
It's reproducible every time by opening an ETL and going to Graph Explorer -> Computation -> CPU Usage (sampled) -> unfold. Just clicking to see the CPU sampled graph list. Sometimes it crashes silently, sometimes with the dialog that lets you debug the crash.
Has anybody experienced problems like this? I don't see any support forum in the Windows Performance Toolkit site, and I would like of course to find a solution for this. Any hints are greatly appreciated, thanks in advance.
PS: reinstalling doesn't help. Neither does removing user preferences. The stack only showed me a problem accessing memory out of bounds, in a "Task" class, but I can't get the debug dialog to show again (it's crashing silently now, every time).
PS2: the only significant change I remember to have done in this past month is installing the CTP of Visual Studio 2015, and letting Windows upgrade a bunch of packages it had pending (I'm in a capped subnetwork and Windows doesn't upgrade automatically).
The VS2015 CTP installs a .Net 4.6 pre-release version. Maybe this .net versions causes the issue. So remove VS2015 CTP and the .Net 4.6 Preview and reinstall .Net 4.5.2.
I have a medium-sized solution with 99 projects that has recently started behaving weirdly:
1) If I try to rename a file through the solution explorer, VS will seemingly hang, but after a long time (10+ minutes) it will complete the rename operation.
2) I also noticed today that switching to between Debug and Release mode seems to freeze VS as well. So far I haven't let it run long enough to see if that actually completes.
I've tried both Visual Studio 2012 and 2013, and both exhibit the same problem, so that seems to indicate the problem might not be with Visual Studio. I've tried to check in the event log if there's anything there, but nothing jumped out on me. I've also rebooted and run checkdisk, but it didn't find anything wrong.
Running Windows 7 Professional on a fairly high-specced laptop with 8GB RAM and a new SSD
Update: apparently if I have renamed a file once, I can keep renaming it (and other files in the solution) immediately. When I restart VS, it's slow again.
Update2: I left the computer running overnight to try to switch from Debug to Release, and it managed to do so in the 14ish hours between me leaving work and getting back here.
Visual Studio can be extremely slow in renaming files if you are using TFS with a "local" workspace as oppose to a "server" workspace, and the total number of files including different versions in the TFS repository exceeds 10,000 items.
Contrary to Microsoft's recommendation, I suggest using a server workspace instead of a local one for much better performance. There are also some other downsides to local workspaces and the only upside is being able to work while your TFS repository is down. That's not much of an upside considering if you can't connect to TFS, you probably can't connect to your LAN and there's darn little work you can do anyway in that situation.
To change to a server workspace for TFS in Visual Studio 2015,
In VS click on File --> Source Control --> Advanced --> Workspaces
In the dialog that opens, select your workspace and click Edit...
Click Advanced... (it does not matter which mapping is selected).
Under Location, select Server and then press OK.
Switching over to server may take ten minutes or more depending on the size of your repository.
Once this is done, renaming files should be nearly instantaneous.
When testing I'd made an attempt at setting up one of the projects to build on a different server, both in Debug and Release mode. I though I'd cleaned up both, but apparently I'd only done so under the Debug configuration.
Apparently meanwhile that server has decided it hates my machine, which makes my machine freeze while waiting for it.
Closing Visual Studio and manually editing the .csproj file solved the problem.
Unfortunately 99 projects is not a medium sized solution for Visual Studio but instead a very large solution. Visual Studio simply doesn't scale well to solutions of this size and you're seeing the effects of that here.
The only way to make this better is to factor out your solution into several smaller solutions.
Building on #Daniel Barbalace's answer, my issue indeed had to do with TFS, but I could not switch to server workspaces. What I ended up doing was removing the mappings to any branches or projects that I am not working on at the moment. There is no magic number but once I seemed to get under 50,000 files (globally for the TFS folder) renaming suddenly went down from 2+ minutes to 3-5 seconds.
In my case "git" cause that,i have a bunch of html files in my commics project,so,when i removed .git folder i have again fast renaming files.
I had the same issue. Renaming one file would take a decade. I found a solution however. When I first check out for edit, renaming becomes very fast again.
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.