What's the difference between retail symbols and checked symbols? - symbols

Windows XP with Service Pack 3 x86 retail symbols, all languages (File size: 209 MB - Most customers want this package.)
Windows XP with Service Pack 3 x86 checked symbols, all languages (File size: 202 MB)
Quoted from here.
What's the difference between retail symbols and checked symbols?

In general, the difference between "retail" and "checked" is similar to a "release" versus "debug" build. Microsoft provides two different kernels, one compiled for regular use and one with extra debug information. The two different builds also have two different symbol tables.

If you are an IT or Computer Science student in college (or if you happen to have access to MSDN's e-Academy software), you will probably have access to the special debug/checked builds of Windows Vista/7. Some professionals in the software development and engineering industries may have installations of the special debug builds as well. Otherwise, whether you come across Home or Professional editions--even Enterprise and Business editions--it will most likely be the retail version. All of those versions will require the retail version of the debugging symbols. However, if you have a debug/checked build of Windows installed, you will need the checked debug symbols.
As Greg has explained, the debugging symbols are basically an address. As far as I understand, they're basically a proper name for a function or item in memory, so when a user is debugging a process or viewing a callstack, he or she will be able to see usable information instead of address offsets.
Greg answered this already as well, but I'll try to elaborate. The retail and debug builds of Windows need different versions of symbols because the operating system files are compiled differently to include more useful debugging information. This makes the addresses for the symbols move ever so slightly, so a different package is required to correctly identify everything in memory.
The one thing I'm confused by is why the checked symbol package is smaller. I would have figured it would be bigger. A guru might know the reason for that. Speaking of which, I'd like to make it clear that I'm no debugger. I'm just fascinated with the science behind it. Nonetheless, I hope this helped you out.
Good luck gdb.

For practical purposes, desription of both packages was given in microsoft article https://developer.microsoft.com/en-us/windows/hardware/download-symbols . For been precise,
"Almost all customers require the symbols for the retail version. If you are debugging a special version of Windows with extra debugging information, then you should download the symbols for the checked version."
In other words, most likely you need retail version.

Related

How to build a software for Windows Embedded CE6.0 R3

I am trying to build a Software for Windows® Embedded CE6.0 R3. But I couldn't figure out how to manage this?
I couldn't find something like an SDK
I don't know which Visual Studio I should choose. (Sometimes I read about VS2005 sometimes 2008)
I think I misunderstood something really generally about this Operation System
Do someone know a good source for resources about Windows® Embedded CE6.0 R3. I just Need Information how to start, and what is needed.
Windows CE is a modular OS, meaning that an OEM has very wide latitude in what may or may not be available in the OS. Because of this, there is no way to have a general "standard" SDK for devices. You could end up building an app against features that don't exist on the target, or you might now have API access to features that do exist. At least that's the argument that Microsoft gives.
My experience (and it's fairly deep) is that if you build an SDK for the same processor as your target and just throw in everything in the OS catalog, it allows you to develop apps for anything. You have to be aware of what your target hardware doesn't support and be somewhat careful to avoid using those features, but it's not that difficult. For example, I've been using one single SDK for probably 5 years and have never had a problem or reason to change.
So, in general, you just need to get an SDK for the same processor. Checking with your device vendor is a good start, but if you find one from another vendor, as long as the processors match, you're probably fine.
As for the version of Studio, it depends on what you're doing. If you are creating the OS itself, you need Studio 2005. If you are only creating applications to run on the OS, you can use Studio 2005 or Studio 2008.

Detailed Explanation on "Re-Hosting" and "Retargeting" both for compilers and binary data (such as .exe or .obj)

Sometimes in s/w companies, customers provide data in multiple formats. There are linkable and executable data that are said to be "Rehosted" and compiled object files that are said to be "Retargeted". I am trying to understand what rehosting and retargeting mean in this area. Is it similar to the Bootstrap theory in computer science? I have the understanding of the following process (if not incorrect):
PROBLEM:
I need to write a compiler for a new language called "MyLang" to run on PowerPC
Solution:
1. I need to write a compiler for a language "MyLang-Mini"; a subset of "MyLang" to run on PowerPC.
2. I need to write a compiler for "MyLang" using "MyLang-Mini" to run on PowerPC.
3. I run the compiler obtained from no. 1 through the compiler obtained from no. 2 to
obtain the compiler for MyLang to run on PowerPC.
IN BESPOKE "T" DIAGRAM (...ISH):
MyLang PowerPC MyLang PowerPC
MyLangMini MyLangMini PowerPC PowerPC(instr.)
PowerPC(instr.)
What I am getting confused about is rehosting and retargeting. How are they coonected to this concept? What am I rehosting and retargeting if I have some binary data such as .exe or .obj? I would appreciate some detailed explanation if possible please!
I know that this will embark onto "CROSS-COMPILERS", but would prefer expert opinions to be sure.
Thanks in advance.
I now know that in s/w engineering:
REHOSTING - If you have a third-party application linkable/executable that requires usage on your host machine, you do rehosting. The target in this case are most often the same (OS platform, processor, etc.). In worst case, there is a virtualisation required. The rehosted application will run as if it was one of the application running in the host machine
RETARGETTING - If you have a third-party source code, you might need to recompile that to match with your target environment. It may also be that you have third-party .o or .obj compiled models and you want to link them with your source code (retargeted) in order to host it on a host machine. Just like REHOSTED application, it will be as if the application was installed on the host machine.
It will be good to know how this is similar to the compiler rehosting and retargeting. Sorry, I am a newbee is this area and will appreciate even a slap on the wrist.

Could I install Delphi and my libraries on a USB key in such a way as to allow debugging of my app on a customers PC?

Back in the days of Delphi 7, remote debugging was mostly ok. You set up a TCP/IP connection, tweaked a few things in the linker and you could (just about) step through code running on another PC whilst keeping your Delphi IDE and its libraries on your development PC.
Today, with Delphi XE2,3,4 you have paserver which, at least at the moment can be flaky and slow. It is essential for iOS (cross platform) development, but here at Applied Relay Testing we often have to debug on embedded PC's that run recent Windows. To do this we have employed a number of strategies but the hardest situation of all is to visit a customer site and wish that one could 'drop in' a Delphi IDE + libraries and roll up ones sleeves to step through and set breakpoints in source code.
It is quite likely - hopefully - that the paserver remote debugging workflow and its incarnations will improve over time but for now I got to wondering how it might be possible to install Delphi + libraries + our source code on a USB key so that with only a minimal, perhaps automated setup, one could plug that key into a PC and be compiling, running and debugging fairly quickly.
I can see that the registry is one of the possible issues however I do remember that Embarcadero once talked about being able to run their apps from a USB key. Knowing how much of a pain it is to install my 20-odd libraries into Delphi though, it is not trivial and needs thinking about.
Has anyone done anything like this or have any ideas of how it might be done?
Delphi does not support what you are asking for. But what you could do is create a virtual machine with your OS, IDE, libraries etc installed in it, then copy the VM onto a USB drive, install the VM software on the customer system, and run your VM as-is. There are plenty of VM systems to choose from.
First, I need to get this out of the way: embedded PCs running Windows?? Sob.
Ok, now for a suggestion: if a full virtual machine isn't an option for this task, application-level virtualization may be. This intercepts registry calls and other application-level information and maps them to a local copy, allowing essentially any application to be turned into a portable version. The good news is that there are free versions of several programs that can turn Windows programs into virtualized apps.
The only one I've personally used is MojoPac, and found it delivered as promised although was very slow running off of a (old, very slow) flash drive.
http://lifehacker.com/309233/make-any-application-portable-with-mojopac-freedom
I haven't used this newer "freedom" version though.
Two other programs I've seen that appear to be popular are Cameyo:
http://www.techsupportalert.com/content/create-your-own-portable-virtual-version-any-windows-program.htm
and P-Apps,
http://dottech.org/26404/create-a-portable-version-of-any-software-with-p-apps/
but I can't vouch for the quality of either of these two.
Hope this helps.

Portability vs Platform Independent

Can someone explain me difference of these? If the program is platform independent doesn't it make it portable too and the opposite?
Platform independent means, these programs can run in "nearly" all operating systems. Doesn't need to be all, but at least MS, Linux and Mac will be fine to use this word.
And, lets dig out the facts behind the word "platform independent".
NOTE: The following sentences are my opinions. If anyone read, couldn't understand the logic behind or doesn't like, just can press on buttons CTRL + W to close. I noted these because Java programmers getting seriously mad when they face this sentences. But it is always open for discussion.
Check please: http://en.wikipedia.org/wiki/Platform-independent_model
Ok don't break the topic and turn back.
Actually and logically, any program needs a platform installer can't be considered as platform independent. For example, if I can't run Java executables without downloading and installing java runtime packages services etc... So how we can say that it is platform independent. If we can say, so nearly 80% of the windows executables are also platform independent since you can run them with virtual machines or WINE on Linux etc. And sure, if Java is platform independent, PHP, ASP, Perl, Python, Ruby etc. all scripting languages are also platform independent!? Aah, sure not...
Hope you got the logic.
But what we can do is, we can compile our (own) softwares for many different OS's. So our software will be "cross platform"
What can be platform independent in real manner is
(as I wrote in top, my opinions)
Uncompiled assembly, C etc codes...
And when it comes to portable, this is something else. For example, the word "portable software" under "windows" operating system means;
Doesn't use registry or Appdata folder for its files or settings.
Works under its own folder, all files needed for it is located under it's own folder.
Also saves it's settings to a file (ini etc) under it's own folder.
And if we go a bit further in meaning, even mustn't rely on specific hardware/software brand, model or unusual mode (like "x" brand screen card, "y" resolution, "z" release of DirectX etc.). But actually you can just ignore the last detail since this criteria is not mature yet to be accepted by all.

Building cross-platform Delphi applications

I downloaded Lazarus, but have worked with Embarcadero Delphi IDE too. I have a question about building cross-platform Delphi applications.
How can I build them under win32 environment? I read the wiki from Lazarus site, that explains how to do it, but I still do not understand it. Is is possible to build and compile application under win32 environment for Linux and MacOS? If it is possible, can someone explain ste-by-step how to do it exactly.
EDIT:
Now is the time for talking about the new XE2 version of the Delphi IDE I think :)
Thanks
What you're asking for already exists in the lazarus wiki site, you need to read these articles.
Multiplatform Programming Guide
Cross compiling
Cross compiling for Win32 under Linux
How to Write Portable Code (nice doc from Marco van de Voort)
Buildfaq
While crosscompiling to a non windows target is possible (and not that hard), getting used to fpc/lazarus and crosscompiling in one first step is a bridge too far. This because Linux is not a very homogenous target and dealing with this variation requires some understanding how libraries and linking works on Linux. This defeats one-button downloadable cross-compile setups to "general" linux. I know, such one-button thingies that work out of the box for everyone would be great, but it is just not going to happen (or only forvery limited distribution-version combinations)
Crosscompiling with FPC is not extremely difficult or rocket science, but the amount of jargon and details can flabbergast uninitiated people, and without background knowledge it is hard to diagnose problems as a result of minor misconfigurations
I recommend to first familiarize yourself with Lazarus/FPC, and only then make the crosscompilation leap. (and the already mentioned buildfaq names some reasons).
Bottomline: install lazarus on Windows and start porting your app. If that succeeds, start using a linux install (or VM) to familiarize yourself with Linux, and Lazarus under it. You'll need a linux install anyway to test.
Only then start thinking about crosscompiling to speed up the process.
CodeTyphon is a powerful Lazarus/FPC one click easy installation package for cross platform native development. It already supports 4 CPU/OS hosts (Win32, Win64, Linux32, Linux64), and 16 CPU/OS targets (arm-Wince, arm-Linux, arm-Embedded, arm-gba, arm-nds, i386-Win32, i386-Linux, i386-FreeBSD, i386-Haiku, x86_64-Win64, x86_64-Linux, x86_64-FreeBSD, powerpc-Linux, powerpc64-Linux, sparc-Linux, sparc-Solaris). More are supported in Lazarus/FreePascal, but others are not yet integrated in CodeTyphon. Did I mention that it is free? One code to rule them all ;-)
The point is that you don't have to waste days for setting up your cross platform environment, since someone has already done the hard work for you.

Resources