|
Richard,
I tried and got thousands of entries saying that the directory name is too long. I was at C:\ and entered "dir bcdedit.exe /s".
The explorer search method works, works differently then XP, but works.
Dave.
|
|
|
|
|
Richard,
I just caught your message edit. Am I still up in the air?
Dave.
|
|
|
|
|
Did you check in C:\Windows\System32 to see if bcdedit.exe is still there? If it is not then it may well be that some other system files have been destroyed (who knows how), so it may be safer to re-install Windows 7.
One of these days I'm going to think of a really clever signature.
|
|
|
|
|
Richard II,
Thank you for responding.
Yes, I did check. It is there, but Windows 7 does not recognize it as valid.
I doubt that the file is modified, it is just that something is telling Windows that it is not valid.
I will copy the file to another location, then boot from the Symantic Recovery Disk and restore bcdedit.exe from my backup, then boot up and use FileCompare (FC) to verify that the actual content is the same.
Dave.
|
|
|
|
|
Member 4194593 wrote: I doubt that the file is modified You can usually tell by looking at its properties.
One of these days I'm going to think of a really clever signature.
|
|
|
|
|
Richard II,
Here is the FC result where bcdedit1.exe is a copy of the restored backup file, BCDEDIT2.exe is the copy of the system file after the Visual Studio file install:
Comparing files bcdedit1.exe and BCDEDIT2.EXE
FC: no differences encountered
The report tells it all. The file is the same as the original (which used to work), but now is ignored.
OBTW, Symantic Recovery Disk works just fine. This is the first time I ever used the recovery feature (have done several backups). The interface is almost exactly like my Windows XP mainstay of Partition Magic DriveImage 7 (Symantic bought Partition Magic and, I guess, Norton Ghost). They did not make too many changes in the basic engine, the Help is different, and they implemented recovery points, and they implemented recovery of individual files and folders.
Dave.
|
|
|
|
|
Sorry, I have no further ideas what may have happened to your system, but I find it difficult to believe that this is due to the install of visual Studio.
One of these days I'm going to think of a really clever signature.
|
|
|
|
|
Richard II,
I watched the install, there are about 30 things it installs, not just a simple Compiler and IDE (including SQL server, etc, etc).
All I know is that bcdedit.exe was working before the install (I used it and set a path to my TOOLS), but not after the install.
Dave.
|
|
|
|
|
Given the number of installations similar to yours it seems strange that no one else has seen this elsewhere. As I said before, my only advice would be to re-install windows 7 and try again.
One of these days I'm going to think of a really clever signature.
|
|
|
|
|
I just went back to your original message to review the problem. You wrote that when you tried to run bcdedit you get the message:
'C:\Windows\System32\bcdedit.exe' is not recognized as an internal or external command, operable program or batch file.
This message normally indicates that the shell cannot find the program in the location that you specified. You then said that you checked and it is there so I don't understand how only that program can not be found when, presumably, all other executables in System32 run OK. If the file was just corrupted then you would get a different message.
One of these days I'm going to think of a really clever signature.
|
|
|
|
|
Richard II,
I have also been working with the masm32 project and one of the members suggested that I needed to elevate my access to cmd.exe. This results in the ability to at least list the contents of the bcd file with all of the variables, but still need a way to be able to edit the values to add new paths. This was not necessary when I first added my TOOLS path, but I cannot remember exactly how I did that at that time.
I also have a MS feedback waiting for my review.
Eventually, I may be able to actually use my system to do my work.
Thank you for your interest in this problem.
Dave.
|
|
|
|
|
If I open a cmd window and call bcdedit it runs fine, without any elevated privileges; however my account is an administrator account.
One of these days I'm going to think of a really clever signature.
|
|
|
|
|
My account is also an administrator account. Still does not help me.
Maybe you can give me some tips on bcdedit usage (that I can use once I get it working). Can you give me the steps you would use to add a path to %path%? I am sure that I did this once (I added the path to my TOOLS to the %path% and it it still there), but can't remember exactly how I did this, and since I can't really use bcdedit at the moment, I can't really experiment with this.
On top of everything else, my mail server (Yahoo) decided to take a hike so I can't read my MS mail. Hopefully, Yahoo will return shortly.
Dave.
|
|
|
|
|
Sorry Dave, I have never used bcdedit, to be honest I don't really know what it is used for. If you want to edit your path variable then use the System item in Control Panel, and select the Advanced Settings and then Environment Variables on the Advanced tab.
One of these days I'm going to think of a really clever signature.
|
|
|
|
|
Richard II,
Thank you, thank you, thank you! That is what I was looking for. Works as advertized, once you know what you are doing.
Dave.
|
|
|
|
|
I think you actually did all the work, but happy to add my little bit.
One of these days I'm going to think of a really clever signature.
|
|
|
|
|
Richard II,
I had found this once before from some on-line source, and that is how I initially set my paths. I could not remember how to do this later. There is no documentation in the Windows 7 Help files about how to modify an environment variable. There are so many different ways to do things in Windows 7 than in Windows XP, and very little documentation on how to do it.
My next problem is how to get the MSDN documentation for Visual Studio 2008. I tried to install it from the CD, but it failed to install. I need to find out how to get a new CD or to download it from MS, but I do not want to have to pay for any MSDN subscription.
Thank you for all the help.
Dave.
|
|
|
|
|
Member 4194593 wrote: I do not want to have to pay for any MSDN subscription. I manage with the MSDN online site[^], which, once you get used to it, is not too difficult to navigate, or search.
One of these days I'm going to think of a really clever signature.
|
|
|
|
|
Richard,
I guess I will have to use that site also. Wish that it had an alphabetical organization instead of a topic organization. At least search gets you the api if you know what to search for.
Dave.
|
|
|
|
|
Richard II,
Well, Yahoo is back, I am off to go down the rabbit hole called MS Feedback. I may find my way out of there.
Dave.
|
|
|
|
|
A DLL can be loaded explicitly by using LoadLibrary and GetProcAddress functions (sometimes called "run-time linking" or "manual linking") or implicitly by linking so called import library into your program and declaring functions in conventional way (sometimes called "load-time linking" or "automatic linking"). The latter method has two varieties: pre-load and delay-load. Pre-loaded DLLs are loaded instantly and unconditionally at the start of the program. Delay-loaded DLLs are loaded when (if) they are first used.
So, in this terms, there are still only two major ways to load a DLL: explicit and implicit. The latter load method just happens to have two sub-varieties. Some people might prefer to interpret this hierarchical classification as a flat one, ending up with three linking/loading methods.
Some companies ask the other ways to load Dynamic-Link Libraries(besieds explict and implict) in their interview.
But I wonder whether exists other ways to load the Dynamic-Link Libraries?
Any help will be appreciated!
modified 29-Jul-12 20:40pm.
|
|
|
|
|
Wow, that's a tough question. I suppose you could try to load it from memory by manually mapping the sections into memory and resolving all the imports. But that's really a hack, and it's very difficult to handle every case the way the Windows Loader does.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
I wrote such piece of code and its surprisingly short. It has many drawbacks you might not spot at first sight but here is a list that came to my mind from the time I played with this: some module related features won't work because your DLL doesn't have a valid windows HMODULE/HINSTANCE handle, so you can't easily use for example resources, your library wont receive DLL_THREAD_ATTACH/DETACH events, you have to write your own GetProcAddress(). You can also use Resources (for examaple dialogs) if you write your own FindResource() and you use CreateDialogIndirect() instead of CreateDialog(), lot of resources have an "indirect" version fortunately. To sum it up: its pain in the ass to load your library "manually" but its fun to experiment with it, and it can hide a "hack" very well in the process space. With this load method you can skip loading the DLL PE header that makes thing harder to detect even for memory sweeps, thats why we used it.
|
|
|
|
|
I'm honored to meet someone who actually implemented this. I once looked into it and I was totally intimidated.
Your list of features that won't work is precisely why I didn't pursue it.
But maybe when I have more time I would experiment with it......
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
Just looked up my sources and Iam thinking about posting up the sources here. I have a similar module hacking related short tip/trick whose rating is almost a 5. For this reason I think that some people might be interested in this stuff but Iam lazy to write a full fledged article. What about posting up a few tips with short intro + sources? For example one for the FindResource, and another with the Dll loading.
|
|
|
|