|
Translate message does what the name suggests: you provide it with a message and it translates it an places the result back onto the same thread message queue. It can't be used to send messages to a different process, because (if nothing else) it doesn't have any means to tell it which process to feed the translated message to.
If a game has messages blocked, there's probably a reason: normally to prevent people from cheating.
Sent from my Amstrad PC 1640
Never throw anything away, Griff
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Previously, our software had to be created for both 32bit and 64bit Windows. Now, product management decided that we do not need to support 32bit Windows anymore (that's great with regard to third party SDKs and drivers).
In almost all of our some 200 projects, the DEBUG and RELEASE configurations have the "Platform target" of "Any CPU" only (only some wrappers of third party components are specialized). Of course, the software will run on 64bit systems with such settings.
But compiling for 64bit only could allow for more compiler optimizations (or am I mistaken?), so I'd prefer to create 64bit executables.
As shown in How do I specify the platform for MSBuild? - Stack Overflow[^] , there is no possibility to simply add a parameter to the msbuild command line, instead every project has to be changed...
What's the easiest way to do so? Or do I not need to care because there's no advantage in doing so?
Note: we use C# with Visual Studio Professional 2015 Version 14.0.25425.01 Update 3.
Oh sanctissimi Wilhelmus, Theodorus, et Fredericus!
|
|
|
|
|
One way to do that is to write an app to modify the .csproj files: they are XML, and contain the Platform:
<PlatformTarget>AnyCPU</PlatformTarget>
It wouldn't take much to knock up a quick app to convert all 200.
Sent from my Amstrad PC 1640
Never throw anything away, Griff
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Bernhard Hiller wrote: But compiling for 64bit only could allow for more compiler optimizations (or am I mistaken?), so I'd prefer to create 64bit executables.
Not really, the compiler doesn't do anything special, it just sets that flag on the binary (which can be modified later, by the way). What matters is the bitness at which the program actually runs. To the C# compiler, "optimization" means simple things such as using fewer temporary variables and branching directly on a condition instead of constructing a boolean out of it and then testing it, that sort of thing.
There are various optimizations that you can do though:
- Drop 32bit versions of dependencies and drop the release that uses them. Sounds like that's the plan.
- Write code that explicitly assumes pointers are 8 bytes (doesn't come up a lot in C# obviously, but you can do it).
- In 32bit mode, FP math gets done with x87 instructions, occasionally this required some workarounds to deal with 80bit/64bit precision mismatches, all of that nonsense can be removed. Most projects didn't bother with this in the first place.
- Boldly using System.Numerics.Vectors all over the place, which is fast (well, some parts of it are fast, definitely double check) in 64bit mode but worse than pointless in 32bit mode.
- Using things from System.Runtime.Intrinsics with X64 in the name, such as System.Runtime.Intrinsics.X86.Sse.X64, without checking
IsSupported and without fallback.
|
|
|
|
|
Thanks for that information.
That means then that I do not need to change any settings, as I won't get any performance improvements when compiling to x64 instead of AnyCPU, except for those special cases you showed (getting rid of those 32bit dependencies is the most important point for me).
Oh sanctissimi Wilhelmus, Theodorus, et Fredericus!
|
|
|
|
|
I read up on it last year, because I have a 32bit Win Forms project and needed to support 64bit Win10.
From what I read, compiling with X64 just creates a giant bloated program that consumes tons of memory.
Using X32 creates a smaller program that is more efficient and compact.
So I opted for Any CPU and it works fine on both Win7 32 bit OS, Win10 64 bit OS. Of course some NuGet libraries gave me issues in which I had to detect the OS and load the correct version.
Several examples given was Office 32 vs Office 64, and why Visual Studio is 32 bit.
Suppose it could be debated again.
If it ain't broke don't fix it
Discover my world at jkirkerx.com
|
|
|
|
|
Maybe the question you should really be asking is, "what improvements will (in performance, efficiency etc.) will be seen by switching to x64?". Since 32 bit code will run fine on 64 bit systems it is important to change for the right reasons.
|
|
|
|
|
Exactly. Compilers do optimize - even the first Fortran compiler described by Backhus did. Now I am in a situation where 32bit support can be removed. Consequently, the compiler could use instructions available on 64bit processors which are not available on 32bit processors. I do not know what to expect here in detail - but I think it is adequate to expect some possibilities.
On the other hand, as others pointed out, the intermediate language may not have so much differences, because it is interpreted by the underlying .Net Framework (which might be optimized for the processor).
Oh sanctissimi Wilhelmus, Theodorus, et Fredericus!
|
|
|
|
|
The 64bit and 32bit JIT engines are (except in .NET Core 2 and 3) diffent, even the old 64bit JIT was already different, with the 64bit versions being better - mostly not thanks to 64bit instructions but because it's a better JIT engine. RyuJIT especially has seen many performance enhancements in recent years, the old 32bit legacy engine (the one you get in non-Core) AFAIK is just its crummy old self without anything fancy like devirtualization and various small tricks. Even the old 64bit JIT engine already had better array bounds check elimination and inlining (couldn't find a good source). On the other hand, the 64bit versions are also working against the inherent disadvantage of wasting double the space on pointers, and C# is an especially pointer-heavy language. So it's not a clear cut win either way and you can easily tune a benchmark to justify either conclusion.
|
|
|
|
|
Thanks for the information. The memory consumption by the large pointers is not such a big issue - our most important application uses some 500 MB, in a device with 4 GB. But (heat production by) CPU usage is important: typically 50% CPU load, and that small box can get very warm.
Oh sanctissimi Wilhelmus, Theodorus, et Fredericus!
|
|
|
|
|
Hi,
Be careful with custom controls. Visual Studio is still a 32 bit process and if you move your entire code base to x64, forms won't open in the designer any more - you'll get an error page.
Ant.
|
|
|
|
|
Hi All,
I'm trying to write a json POST message using .NET 4.5, with VS 2015.
The following code is able to post the message successfully, but for some odd reason, about (1) minute after the code executes, and closes. The server that received the message, will get a crash alert, and shutdown the message service.
I tried placing a sleep statement at the end of my code for 2 minutes, and that does give the server time to abort the connection, without taking down the service. I also checked the ServicePointManager, RestClient, and IResponse classes, and I dont see a Close, or Dispose method I can use to close the connection on my end. Any idea how I can close my application successfully without taken down the server services?
using RestSharp;
using RestSharp.Authenticators;
using Newtonsoft.Json;
ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;
var client = new RestClient("https://testdev.com:5109/Test");
var request = new RestRequest();
request.Method = Method.POST;
request.AddParameter("application/json", json, ParameterType.RequestBody);
request.RequestFormat = DataFormat.Json;
IRestResponse response = client.Execute(request);
Thanks!
|
|
|
|
|
Just in case you don't know, there is a dedicated sub-forum on StackOverFlow for RestSharp: [^]
«One day it will have to be officially admitted that what we have christened reality is an even greater illusion than the world of dreams.» Salvador Dali
|
|
|
|
|
Well ,that title is confusing... 
I have this list:
var list = new List<(int Key, string Value)>();
list.Add((1, "foo1"));
list.Add((1, "foo2"));
list.Add((1, "foo3"));
list.Add((1, "foo4"));
list.Add((2, "bar1"));
list.Add((2, "bar2"));
list.Add((2, "bar3"));
list.Add((2, "bar4"));
list.Add((3, "baz")); From that list I want a new list:
(1, "foo2")
(1, "foo3")
(1, "foo4")
(2, "bar2")
(2, "bar3")
(2, "bar4")
Notcie the first occurances of any "key/group" are removed in the result list.
These entries are removed: (1, "foo1"), (2, "bar1") and (3, "baz")
I have no clue how to do this. I have tried to create a solution, but I don't know how to find the first entry of a group and remove it using LINQ. The .Distinct() and .First() methods seems needed in someway, but I cannot figure it out. I'm sure I can hack something ugly with foreach loops and new lists, but I would prefer a solution with LINQ.
Any suggestions for a solution?
Best regards
|
|
|
|
|
Try:
var x = list.GroupBy(g => g.Key).Select(grp => grp.Skip(1)).SelectMany(i => i);
Sent from my Amstrad PC 1640
Never throw anything away, Griff
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Thank you VERY much! 
|
|
|
|
|
You're welcome!
Sent from my Amstrad PC 1640
Never throw anything away, Griff
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
You need a small tweak to get a one-off instance like 'baz in the result:
var x = list.GroupBy(g => g.Key).Select(grp =>
grp.Count() == 1
? grp
: grp.Skip(1)).SelectMany(i => i);
«One day it will have to be officially admitted that what we have christened reality is an even greater illusion than the world of dreams.» Salvador Dali
|
|
|
|
|
Yes, but his original question specifically excluded "baz".
Sent from my Amstrad PC 1640
Never throw anything away, Griff
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
I tear my hair out, throw myself at your lotus feet, and beg mercy while singing [^] 
I'm such a sucker for a stray 'baz 
Been a very weird day !
«One day it will have to be officially admitted that what we have christened reality is an even greater illusion than the world of dreams.» Salvador Dali
modified 23-Sep-19 13:17pm.
|
|
|
|
|
Never any need for that Bill - you are Forgiven[^] of course.
(And I love Sharon's voice)
Sent from my Amstrad PC 1640
Never throw anything away, Griff
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
lovely voice, reminds me a little of Sarah Brightman. thanks, Bill
«One day it will have to be officially admitted that what we have christened reality is an even greater illusion than the world of dreams.» Salvador Dali
|
|
|
|
|
Please stop singing immediately. this is supposed to be a serious forum.
|
|
|
|
|
Okay, got it ... I'm switching to screaming 
«One day it will have to be officially admitted that what we have christened reality is an even greater illusion than the world of dreams.» Salvador Dali
|
|
|
|
|
That would be fine in Q&A 
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
