Trying to do some work on an old FoxPro and VB6 legacy application and I've run into a brick wall.
The VB6 part of the application creates three .qpr file which, I understand, are just SQL queries. It then calls an external .fxp file, which is compiled foxpro code. I am not sure exactly what this is - however, I am assuming it to be a compiled version of an identically-named .prg file in the same folder, which contains the following code:
COMPILE "\\Count\Database\Sql_Result.qpr"
WAIT TIMEOUT 1
COMPILE "\\Count\Database\Sql_Total.qpr"
WAIT TIMEOUT 1
COMPILE "\\Count\Database\Sql_Query.qpr"
Those are the .qpr files which the VB6 app generates.
When you run this compilation command, it seems to do something. No error is thrown. Yet I can't see it's done very much.
What is the product of the above compile commands, and how can I find it?
The .QPR programs are nothing but a simple .PRG file with renamed extension. When the main VFP app calls the .qpr program, it just runs the query, the resulting cursor result is created and then VFP does with it whatever it needs to.
If your VFP application is compiled into an EXE, and the original underlying EXE was compiled with .qpr code, then the new versions of .qpr would not be impacted... but not enough to confirm the situation of your app design / implementation.
Related
Okay, I've been struggling with this for full last couple of hours. I have a Windows 7 32-bit installation, on which I'm trying to compile some old code. I do not have any working knowledge of VB, but I'm trying to build a VB6 project which is part of the code base. The code compiles and when I run it after full-compile, it runs. But I can't seem to find where this file is. Task manager shows VB6 as process. It is not present in %TEMP%, and not in my project directory. Running an exhaustive search on my single drive configuration, I can find only one entry by this name, and this file has a timestamp older than current time. I attempted delete on this one while the debugger was still on breakpoint and it succeeded. As last resort in prefetch directory, I deleted that entry also, but magically this file still runs when on VB6. What must have been going on?
When you run an application within the VB6 IDE, it entirely runs within the VB6 IDE. Unlike some other languages, it isn't creating an executable file and then running it separately while hooking a debugger up, it just starts running your code using the VB interpreter.
To create a standalone .exe file, you need to create it separately. In the "File" menu, choose "Make projectname.exe". For full details, see "Making and Running an Executable File" in the Visual Basic 6 Concepts guide.
I've written a command-line OpenCL compiler. I'd like to have VS compile my kernel source files using this whenever I build the C# project that includes them. I've looked around and found information and custom build tasks, custom tools, etc, but I haven't been able to get it to work correctly.
How can I tell VS to run my exe on the source files in the same way that it runs the c# compiler, etc for other files in the project?
I report errors from this tool by calling Console.Error.WriteLine(). This dutifully places the errors in the Output pane, where I can double-click them, taking me to the appropriate place in the .cl kernel source file. However, the errors don't appear in the VS error panel. ??
Alternatively, if anyone's aware of an existing OpenCL compiler - it's annoying to have to run the host application just to compile the kernel - I'd appreciate a link.
I've managed to get this working by adding a post-build step to the project options. However, I'd really prefer for this exe to be run for every *.cl file in the project.
Update I had neglected to include an error code when formatting my error messages. Correcting them to match any of the formats listed here took care of that issue. Still trying to figure out how to associate an exe with a given file extension, though.
Hey I developed a small application and would like to compile it, however it comes with loads of extra stuff I dont want. All I want is a stand alone .exe file but instead I am getting pdb vshost.exe files etc. Is there anyway to get rid of these as I just want 1 .exe
Just copy/paste the exe file out. VS uses those files internally, and one is full of debugging symbols. Your going to want it if you plan on stepping into the code.
All these ''extra stuff'' is not required to run your ''small application''. You can verify that by copying the .exe file to a location where it will be standing alone indeed.
If it is not standing alone, as you say in the comment below: perhaps part of your code does compile to .dll, or you reference external dlls? Could you supply a list of filenames of files that are created?
We're going through a massive migration project at the minute and trying to validate the code that is deployed to the live estate matches the code we have in source control.
Obviously the .net code is easy to compare because we can disassemble. I don't believe this is possible in vb6 exes because of the manner of compilation.
Does anyone have any ideas on how I could validate the source code and the compiled executable matches the file I have in Live.
Thanks
Visual Basic had (has) two ways of compiling, one to the interpreter ( called P-code) that would result in smaller binaries, and a second one that generates "regular" windows .exe file (called native) that was introduced because it was supposed to be fastar than p-code; although the compiled file size increased with this option.
If your compilation was using p-code, it is in theory possible to restore the sources.
Either way is pretty difficult to do, but there are tools that claim they can partially do this, one that I know of ( never tried but there is a trial version ) is VB-decompiler
http://www.vb-decompiler.org/
Unfortunately that's almost impossible. Bear in mind that VB6 code compiled on different machines will have different exe sizes and deployment requirements.
This is why the old VB'ers had a dedicated machine to compile their code.
This won't help you with already deployed items, but if you upped the revision number on every compile (there is a project setting to do this for you automatically) then you could easily compare version numbers.
My old company bought a copy of that VB-Decompiler and as noted before VB5/6 generates P-Code extra, that tool did produce some code and if not Assembly code which could be "read".
If you have all the code you compiled, you could compare the CRC's of that code to what is deployed in the field. But if you don't have the original compiled code, depending upon how you compiled the code you (if you used P-Code rather than Native Code you may be able to disassemble but the disassembly will look nothing like your source code). I doubt you would have shipped the PDB's with the exe's, but if you did, you could certainly use those to compare with the source code in your repository.
Have a trusted computer that can check out the various libraries and exes you make and compile them automatically. Keep those in a read-only but accessible location. Then do a binary comparison between the deployed site and your comparison site.
However I am not sure of the logic over disassembling the the complied units. My company and most other places I know of use a combination of a build computer and unit testing. In our company the EXE we make is a very thin shell over a bunch of libraries. For example a button click will be passed to a UI Active X DLL that does the actual processing. What we do after a build is run a special EXE that perform our list of unit test. If they all passed we know our libraries, where 90% of our code is, are good. As for the actual EXE we have a hand procedure that takes about two hours to do and then we are good. IIt is rare for any errors to happen in the EXE.
I have an executable (compiled by someone else) that is hitting an assertion near my code. I work on the code in Visual C++ 2003, but I don't have a project file for this particular executable (the code is used to build many different tools). Is it possible to launch the binary in Visual C++'s debugger and just tell it where the sources are? I've done this before in GDB, so I know it ought to be possible.
Without the PDB symbols for that application you're going to have a tough time making heads or tails of what is going on and where. I think any source code information is going to be only in that PDB file that was created when whoever built that application.
This is assuming that the PDB file was EVER created for this application - which is not the default configuration for release mode VC++ projects I think. Since you're asserting, I guessing this is a debug configuration?
Short of any other answers, I would try attaching to the executable process in Visual Studio, setting a break point in your code and when you step into the process you don't have source to, it should ask for a source file.
Yes, it's possible. Just set up an empty project and specify the desired .exe file as debug target. I don't remember exactly how, but I know it's doable, because I used to set winamp.exe as debug target when I developed plug-ins for Winamp.
Since you don't have the source file it will only show the assembly code, but that might still be useful as you can also inspect memory, registers, etc.
Update
If you are debugging an assertion in your own program you should be able to see the source just fine, since the path to the source file is stored in the executable when you compile it with debug information.