As ratbak noted - Cursors are slow. Cursors work on a row by row basis rather than on the set of data. The more rows you have, the slower the cursor gets. It may be that you have hit a bottleneck that you cannot solve with hardware or software apart from rewriting the SQL code to not use cursors.
As for a solution to performance issues, there is soo much to unpack there. Upgrading to newer SQL Server may help as the query optimizer is improved and you get some new tools you can use to help with your queries (such as the LAG and LEAD functions, which may or may not help in your case). On top of that, do you know where the performance issue is? Is the performance issue on the client side or the server side? Windows XP is pretty ancient technology (and not a secure OS by any means) and it could be the problem is entirely on the client side.
Now, onto analyzing those XML's - they appear to be doing different things. A very quick look at them, the "OK" one declares and sets a bunch of variables and then runs an execute cursor command. The problem one, the first thing it does is insert a bunch of data (looks like it does it by dynamic SQL). Just skimming through the XML files, I don't see where there is an identical query to do a comparison with for performance. The XML doesn't have a lot of useful information in it. Execution plans are what you are going to want to review performance differences.
If it is stored procedures, you may have parameter sniffing problems. Could be statistics are out of date. Could be network hiccups.
My first step would be to determine if this is a client machine issue OR a server issue. If nothing changed on the SQL side and it was fast before, run some tests on your own of queries that are being reported as slow. If the queries are not slow, I'd look at the XP machines.