|
arnold_w wrote: ??? Conspiratorial much?
Not going to answer your questions anymore.
Enjoy.
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
What you're trying to do is something that very, very few people ever mess around with let alone succeed at.
You're going to put FAR more work into writing another application that can modify your compiled application than you would EVER do by simply adding the servers to the source code and recompiling!
That's what you're doing with modifying an .EXE anyway, but you're just trying to do it the super-difficult way.
|
|
|
|
|
If he owned the source and knew what to do with it, there wouldn't be a question. For all we know, this might be a medical application.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
Yeah. I see no reason at all for him to do what he's describing unless he didn't have the source for the app. Like you, to me that means a vendors application.
|
|
|
|
|
If you read above, you'll see that I was asking if there was something similar to a C-programming linker script in C# and I asked if it was possible to place the array in the end of the .exe-file. Why would I be interested in those approaches if I didn't have the source code and am able to recompile it?
I was thinking someone would suggest something along the lines of putting the array in a separate dll and then do something clever with assemblies (which I have no experiences with). If this is possible, this would be perfectly fine with me. Again, how could I use this if I was trying to hack someone else's .exe-file and not implement in my own project?
If you think about it, this would be very useful to avoid having a (separate) file that remembers the user's preferences (e.g. list of recently used documents, use spaces instead of spaces, etc). When you exit the application, you would just update the array that contains the user preferences (of course, since the executing file it locked, you first rename the executing file, then create a new file with the original file name and then self-destruct the original file).
modified 4-May-20 4:30am.
|
|
|
|
|
arnold_w wrote: If you think about it, this would be very useful to avoid having a (separate) file that remembers the user's preferences (e.g. list of recently used documents, use spaces instead of spaces, etc). When you exit the application, you would just update the array that contains the user preferences (of course, since the executing file it locked, you first rename the executing file, then create a new file with the original file name and then self-destruct the original file).
Huh? Are you serious? Or do I completely misunderstand what you want to do?
It sounds to me as if you want to save one user's preferences in the executable file itself, writing back a modified .exe after removing the old one. Right? If that is it, it is the craziest proposal I have seen for a while!
Re. user preferences: We are not in the Linux world. Using separate files (type ".ini" or ".rc_something") is NOT the proper way to do it. User preferences are stored in under HKCU in the registry. How do you plan to handle different users of the same executable - or do you plan to give each user his own executable for his own private modification?
Under any circumstances: Consider executables as non-writable files - most of all in a managed world. You have left the management of modules to dotNet, and you cannot poke around with a long stick into that management. What you are suggesting is a sort of self-modifying code. Leave that to the assembler guys! Self-modifying code is completely unmanagable! (not only in the sense of dotNet, but generally speaking)
Sure, you are only modifying parameters to some funcitons, but it is not seen as external input at run time, it is hidden within the code itself. So it appears as the code has been changed from one run to another, with no external input. That is functionally identical to the code modifying itself.
In a managed runtime, you do not control the memory location of the managed modules - that is an essential part of the management (that you have left to others). Although you can build a single, fully compiled .exe-file from C#, this is really not the standard way: Assemblies are distributed in a "half-compiled" form, as CIL (Common Intermediate Language), where the final compilation steps are done when the assembly is first used. Until this last complilation is done (this is where differnet instruction sets etc. are taken into consideration), memory addresses are not known. At run time, the addresses may vary from one machine/CPU to another.
So there is no "linker script" for the entire application the way you seem to expect. It is all done dynamically. When you create a self-contained .exe, you are really doing part of the run time handling in advance. But since the "real" dotNet assumes that this is done dynamically, there are no provisions for e.g. controlling memory addresses from outside. Memory placement is handled in other ways, so there is no need to. Or reason to. It doesn't belong in a managed environment.
If you feel that your proposed solution is the only viable alternative, then I don't think managed code is for you. Consider assembly code, or possibly pure C.
|
|
|
|
|
arnold_w wrote: something similar to a C-programming linker script in C#
No, there isn't.
arnold_w wrote: possible to place the array in the end of the .exe-file
No, it's not.
arnold_w wrote: this would be very useful to avoid having a (separate) file that remembers the user's preferences
It's also the most insecure way of storing options. .EXE's are locked by the system while they are loaded into a process, so a running .EXE cannot "rewrite itself" (without going though extraordinary lengths) to update options selected by the user. This has nothing to do with C#, or any language, but with how Windows itself works.
Why is storing writable options in an executable insecure? Think about it. What else is very desperate to "rewrite" an .EXE? Hint: Viruses.
|
|
|
|
|
I would strongly question the suitabilty of C# (or any other sort of "managed" code, e.g JVM based) for embedded code.
If your embedded code is executed on a processor with at gigabyte of RAM, you might successfully run e.g. a user interface written in a dotNET (or JVM) language. But for hardware-related functions, such as handling I/O device buffers or interrupt handlers, managed code is not your first choice.
|
|
|
|
|
I'm not writing an embedded application, it will be executed on a standard PC running Windows 10. The embedded exempel was just an analogy.
|
|
|
|
|
If this is a life and death matter then cost is no object. In that case, hire a team of Software Engineers to Reverse Engineer the existing code. One tool I have used is IBM Rational Rhapsody. It's about $50000, but if it's that important, cost should not stand in the way.
|
|
|
|
|
Thanks, but I have all the source code right in front of me and I wrote it myself.
|
|
|
|
|
The question was how to change in inside the .exe file. If you have the source file, how is there a question?
|
|
|
|
|
The .exe file itself should change the array inside another .exe-file (which happens to be a copy of the original .exe-file) during runtime.
|
|
|
|
|
You can load the array from any number of (safe) sources. Why "inside" an executable?
You can change the sourcecode from the executable and compile it again from the running program. Seems very excessive though.
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
It seems like that would be unsafe and would create unnecessary vulnerabilities to Hacking and Malware.
|
|
|
|
|
You can't; well you can but the complications arising from such an activity would take years to get right. And as soon as the exe file is rebuilt all your addresses will be wrong. It seems to me you are trying to solve a problem that does not exist. You need to put all your text data in some file format that only your application can understand which is far less difficult than trying to hack the executable.
|
|
|
|
|
If the number of elements can change, don't use an array, use a List<byte>.
|
|
|
|
|
Can only conclude from your evasiveness you're trying to modify someone else's exe and you don't have the source code. Otherwise, you would make a large enough array to hold any "future" "patched" entries.
It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it.
― Confucian Analects: Rules of Confucius about his food
|
|
|
|
|
Hi all!
I've got a Windows Forms (C#) project with a combobox that is populated when the form loads
The problem is that the loading of the combobox is slow, and since the loading is done when the form is trying to display the entire form isn't shown until the combobox have been populated. This can in some circumstances be 20+ seconds.
I've tried the code below, using async and await , but it not works....return error :
"This async method lacks 'await' operators and will run synchronously. Consider using the 'await' operator to await non-blocking API calls, or 'await Task.Run(...)' to do CPU-bound work on a background thread."
Any help will be appreciated....
Thank you...
private async void Form1_Load(object sender, EventArgs e)
{
await Task.Run(() =>
{
LoadMyCombo();
});
}
private async void LoadMyCombo()
{
OleDbConnection con = new OleDbConnection(conex);
string strSQL = "select * from Customers order by cust_name";
try
{
con.Open();
OleDbDataAdapter adapter = new OleDbDataAdapter(new OleDbCommand(strSQL, con));
DataSet ds = new DataSet();
adapter.Fill(ds);
mycombo.DataSource = ds.Tables[0];
mycombo.ValueMember = "code";
mycombo.DisplayMember = "cust_name";
}
catch (System.Exception erro)
{
MessageBox.Show("Error.... " + erro.Message);
}
|
|
|
|
|
Your design probably needs to be looked at if the combo takes 20 seconds to load, you are trying to load way too many records, try preceding the combo with a filter turning it into a search.
If there are more than 100 records in the combo then it is unusable.
Never underestimate the power of human stupidity -
RAH
I'm old. I know stuff - JSOP
|
|
|
|
|
Thanks for reply Holmes, but there are aprox. 34,000 records to load from the table 'Customers'.....and I can´t filter only 100 or 200 records, because the user needs to choose a customer from the list....
How can I deal with this...?
Thanks in advance...
|
|
|
|
|
Carlos58 wrote: 34,000 records to load from the table 'Customers'
And there is your problem! That is sheer lunacy, think about the workflow from a users POV. He/she approaches you form, they MUST know something about the customer before they start, they are not going to pick a random customer from 34k.
You MUST allow them to enter some text (usually 3 characters) to filter the selection if the name is the criteria, THEN you populate the combo.
If the name is not known the they must have some other information to filter the list by - geographic, product, size, credit rating, there must be some knowledge about the customer they can use to filter the list.
Never underestimate the power of human stupidity -
RAH
I'm old. I know stuff - JSOP
|
|
|
|
|
Ok Holmes... sorry, but I didn't know about this C# limitation ....I will accept your suggest, allowing them to enter some text.
Thank you !
|
|
|
|
|
This isn't a limitation of C#, but of how Windows and controls work.
The combobox control you drag over from the toolbox is just a wrapper for a standard Windows control from the Common Controls Library. The way these controls works requires sending messages to the controls to get them to do things, like add an item to a collection in your combobox.
|
|
|
|
|
That is not a technological limitation, it is common sense.
If you were to create the Google search engine, would you have a zillion answers (the entire database) on a single web page without a textbox where one can enter a question?
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
