If you want to migrate a 32 bit application to a 64 bit OS, What all would you check?
NOTE : [I][This question was asked by Rita][/I]
Printable View
If you want to migrate a 32 bit application to a 64 bit OS, What all would you check?
NOTE : [I][This question was asked by Rita][/I]
[B]Lokesh[/B],
I could see that you are posting the questions asked by others here for some time now.
I was wondering if the questions were asked in this forum? If so, why re-post the same thing when you can just move the thread here?
Kindly let me know where these posts were orginated from. If there is a sophisticated way of getting them here, we should follow that method.
In order to improve our forum indexing we are already trying to urge people to post questions in the right places. I think we should urge them more often. And if we are moving the threads, they should be informed.
(I am not sure of the mechanism of your posts. Hence I shall not blabber too much:p )
Cheers,
Kalayama
kalayama,
They are asked by Visitors from Ask Question from home page not in posted in forum... All we have is Name ... since email is optional...
If the questions are really interview questions, we keep them in interview questions sections.. if not they will be moved to forum.
THanks,
Oh! That's news for me. In fact it makes sense to move these things into the forum.
Anyway, thanks for the update Admin.
Woulndn't poke my nose in this any further in this regard :o
Cheers,
Kalayama
wud be better if some one answers for the question posted above
HI,
Following article have everything about 32 and 64 bit :---
Overview of 32-bit and 64-bit objects
It is important to generally understand how 32-bit and 64-bit objects are related in a computing environment, since there can be several dependencies between them that can affect everything from what hardware you purchase to how you deploy your applications.
32-bit and 64-bit hardware
32-bit computer hardware uses 32 bits to represent memory addresses and to process instructions and data. 64-bit hardware uses 64 bits to do the same thing. In general, 32-bit operating systems run on 32-bit hardware and 64-bit operating systems run on 64-bit hardware, although it is possible to run 32-bit operating systems on some 64-bit hardware.
32-bit and 64-bit operating systems
Operating systems consist of a kernel that interfaces directly with the hardware and operating system libraries. Operating systems come with either a 32-bit or 64-bit kernel, or, in some cases, both. In general, 32-bit operating system kernels can exploit four gigabytes of real memory (the physical RAM shared by the operating system and the running applications), whereas 64-bit operating system kernels can exploit more than this. Of course, some 32-bit operating system kernels can exploit more than four gigabytes of memory, but don’t do this as well as 64-bit kernels. 64-bit kernels may be required on some operating systems to run 64-bit applications, which cannot be run if a 32-bit kernel is in use. This is the case with all UNIX® operating systems, with the exception of AIX®. On AIX, a particular exception, you can run 32-bit and 64-bit applications with either a 32-bit or 64-bit kernel; however, to prevent scalability problems it is better to use the 64-bit kernel even when running 32-bit applications.
Operating system libraries are important, because they are required to build and run applications. To build 32-bit applications, you have to link to 32-bit system libraries. To build 64-bit applications you have to link to 64-bit system libraries. Having the 64-bit system libraries available in a particular operating system doesn’t necessarily mean that the system is actually capable of running 64-bit applications. This is often true of the 32-bit Windows® operating system, which allows you to cross-compile and link 64-bit applications without being able to run them. This is also true of the UNIX platforms, because there are cases where you can install 64-bit-capable versions of operating systems on 32-bit hardware and cases where 32-bit kernels are incapable of running 64-bit applications. Essentially you can consider a 32-bit operating system to be one that only has the capacity to run 32-bit applications, whereas 64-bit operating systems can also run 64-bit applications, although this capability requires the use of 64-bit hardware and might additionally require the use of a 64-bit operating system kernel.
32-bit and 64-bit applications
32-bit applications are compiled such that memory addresses are 32-bit (four bytes) in size. These applications can directly exploit up to four gigabytes of virtual memory - the memory potentially available for use on a computer. This virtual memory constraint is present regardless of the amount of real memory (RAM) available on the system to be shared between the operating system and other applications. 64-bit applications on the other hand are compiled such that memory addresses are 64-bits (eight bytes) in size and can use more than four gigabytes of virtual memory without restriction. Operating systems typically also impose additional virtual memory restrictions on applications, and the theoretical maximum virtual memory per application may be as little as 1-2 gigabytes, even though it may have 32-bit addressing capability.
When you compile an application on a 32-bit or 64-bit platform, by default it is generally compiled to run on that particular platform. You can create 64-bit applications on 32-bit operating systems and 32-bit applications on 64-bit operating systems with some compilers by using special compiler-specific compile options and by appropriately linking to 32-bit or 64-bit libraries where appropriate.
32-bit applications can generally be run on both 32-bit and 64-bit operating systems, although many operating systems cannot run 64-bit applications if they employ a 32-bit kernel.
Build applications so that they support cross-platform (32-bit/ 64-bit) deployment
To minimize the likelihood of application run-time problems you should build and test application code on the platform in which the application will run. If this is not practical, for example if the required compilers are not available, you can build applications on one platform and then deploy them to the platform they will run on, but special care must be taken when linking applications and when specifying run-time library paths.
To function properly, 32-bit DB2 applications must be linked to a set of 32-bit DB2 libraries and 64-bit DB2 applications must be linked to a set of 64-bit DB2 libraries. 32-bit or 64-bit specific versions of these libraries can be found in the following default directory path depending on the platform:
$INSTHOME/sqllib/lib (UNIX)
$INSTHOME\SQLLIB\lib (Windows)
where $INSTHOME is the home directory of the DB2 instance owner.
Procedure for building 32-bit and 64-bit applications for deployment to 32 or 64-bit DB2 instances
Connect to a database
Connect to a 32-bit database for a 32-bit application or connect to a 64-bit database for a 64-bit application.
Precompile the application to create a package for the application.
Compile the application.
Compile the application in 32-bit mode for a 32-bit application or specify a 64-bit mode compiler option to create a 64-bit application.
Link the application with the appropriate 32-bit or 64-bit DB2 libraries and optionally specify the run time library path:
Link the application
For a 32-bit application being built in a 32-bit DB2 instance that is to be deployed to a 32-bit or 64-bit DB2 instance, link to the libraries in the default DB2 library path or explicitly specify the 32-bit DB2 library directory.
For a 64-bit application being built in a 64-bit DB2 instance that is to be deployed to a 64-bit DB2 instance link to the libraries in the default DB2 library path or explicitly specify the 64-bit DB2 library directory.
For a 64-bit application being developed on a 32-bit platform, link to the libraries in the 64-bit library directory.
Specify the run time library path (optional)
For a DB2 application to run properly the run-time library path must include the DB2 libraries that were used to link the application otherwise the application will fail with a library load error. The run time library path can be explicitly set at link time or can be specified at application run time. If the DB2 libraries used to link the application are not in the default DB2 library directory at run time you must explicitly specify where these libraries can be found. Techniques for specifying the run time library path are detailed below.
Bind the application to a database on the target server.
Specify the application run-time library path using an absolute path
When you deploy an application from a source computer to another target computer, it is important to consider what the run-time library path specification is on the target computer, since any relative paths you used when linking the library on the source computer may be invalid on the target computer. Thus it is often very useful to specify the run-time library path with an absolute path when you link the application using an additional linker option - most compilers provide support for this or just prior to running the application.
Regards
Nikhil Rattan
I don't know how old you are in forum world. I think you are relatively new around here.
There are some very basic rules to be followed whenever you post.
1) When you are posting the article which is written by someone else, [B]ALWAYS PUT THEM IN QUOTES[/B]
[QUOTE]Like this[/QUOTE]
2) If possible post the link to the article.
As in your case your article was flicked from,
[url=http://www-128.ibm.com/developerworks/db2/library/techarticle/dm-0410evans/]32-bit and 64-bit application development with DB2 UDB V8.2[/url]
Please edit your post to reflect the article in QUOTE.
[B]Moderator[/B], if Nikhil is unable to do it, kindly do the work for him.
Thanks.
Kalayama
Thanks Kalayama ,
Really i am new to this forum. I will take care about tht.
Regards
NIkhil Rattan
Wow!! Great piece of infmn.. I owe a big thanks