We have 2 machines in which we run IE selenium Test scripts. In both the machine IE 32 bit is configured. In one machine it types faster and in another machine it types each word. So in that machine i changed the IEDriver bit version as 64 and it worked as expected.
My question is, how the IE driver bit is determined as 64 or 32. Is there any relation between OS bit version ?? like if OS is 64 IE should also be 64 ?
There are technical reasons why the “bitness” of the driver must match that of the browser, mostly stemming from the fact that the driver uses Windows hook procedures for processing keystrokes by default. Those technical reasons are outlined in a blog post written by the driver author (me) some years ago. The tricky bit is knowing whether the browser is actually 32-bit or 64-bit.
You see, IE uses multiple processes when browsing, notably a broker process (which handles the outer frame of the browser), and content processes (usually one per tab, which actually renders the content). Starting with IE10, though, the challenge is that those processes (the broker and the content processes) can have different bitnesses. In fact, on 64-bit Windows, this is the default, where the broker process is 64-bit, and the content processes are 32-bit. Element interactions like sending keystrokes happen in the content process, so that’s what the driver must match.
That means the most common case is that one should use the 32-bit IE driver, even on 64-bit Windows. It must be pointed out that there are some cases where one can get a 64-bit content process (usually based on Enhanced Protected Mode), but these are a vast minority of cases.
If you use IEDriverServer.exe 32-bit execution will be faster and if you use 64-bit execution will be slower irrespective of your OS. So, use 32-bit as its faster. I have tried with both 32 and 64-bit, trust me 64-bit is way too slow.
From https://github.com/SeleniumHQ/selenium/wiki/InternetExplorerDriver#internet-explorer-driver:
The driver supports running 32-bit and 64-bit versions of the browser.
The choice of how to determine which "bit-ness" to use in launching
the browser depends on which version of the IEDriverServer.exe is
launched. If the 32-bit version of IEDriverServer.exe is launched, the
32-bit version of IE will be launched. Similarly, if the 64-bit
version of IEDriverServer.exe is launched, the 64-bit version of IE
will be launched.
AFAIK, you can run either the 32 or 64-bit driver on 64-bit Windows; I'd expect that you can only run the 32-bit driver on 32-bit Windows.
Anecdotally, the 32-bit driver is considered "faster" than its 64-bit counterpart. But--given that perceived speed is influenced by the system-under-tests's CPU/RAM--that would need to be benchmarked to be certain. That being said, I have previously used the 32-bit version on 64-bit systems because it did appear faster (especially WRT to text entry).
Related
I'm working on a project which uses the D2XX drivers from FTDI chip.
We are delivering the ftd2xx.dll file as part of our application. As far as I understand, the other files (e.g. ftdibus.sys) are installed on the system (at least for Windows) where the application runs. Linux is also a target for us, but let's ignore that for simplicity now.
My question is regarding the relation between these files? If, for example, I upgrade the ftd2xx.dll file delivered with our application, will users have to install the newest drivers? What if they do not?
In addition to the specific FTDI drivers, any general source of information on this area is also very welcome.
I used to work on a project that made use of FTDI's D2XX library.
There is no tight coupling between the exact version of ftd2xx.dll and ftdibus.sys. I believe the interface between ftd2xx.dll and the kernel mode driver is version independent at the basic feature level (at least since version 2.04.06 or so). There is even functions in the DLL to query DLL and driver versions respectively.
Thus, it can happen that they are 'out of sync'. I.e. ftd2xx.dll could be one from a more recent release than ftdibys.sys or vice versa. That is not a problem as such.
You are of course in complete control of the ftd2xx.dll version, but how does the driver package get installed? Is it installed as part of your application, or do you rely on the user obtaining the driver from another source? If your application has an installer, it could be an option to include FTDI's driver package in the installation. Thereby you will know which driver version is available.
What can be really tricky (and what has caused me headaches) is if there are other devices on the PC that use FTDI's chip. If such a device is supplied with media containing an older version of the driver and the user chooses to install this driver, it will simply overwrite any existing version of the driver (e.g. the version that your installer provided). This is a potential cause of regression, because FTDI has resolved a lot of bugs in the driver over the years.
If I were you, I would check the driver version at runtime and compare it to a version that is known to work (the version that you tested your application with). If the driver is older, suggest the user to upgrade it. Otherwise I would assume it is compatible.
I am working on the development of a Java application that loads native library files to perform some calculations. The application uses JNI to load the libraries. This application should work on Windows and Linux environments (on both 32-bit and 64-bit).
During the compilation process, we compile C code to library files (32-bit and 64-bit dlls for Windows, and 32-bit and 64-bit .so files for Linux environments). These .dlls and .so files are included in the distribution file, and are referenced when Java is called by using the -Djava.library.path parameter.
I am now testing the application on a few different machines. I am initially focused on 64-bit Windows environments. The strange thing that I have encountered is that on some 64-bit machines the application loads the correct .dll files successfully, but on some other machines it does not load the .dlls.
I thought that the problem might because of a difference in the processor type between the machines (ie. that the dlls were compiled for one processor type and other processors types cannot use them).
However, it works on one machine, and does not work on another machine that has the SAME processor:
It works on a HP laptop running Windows 7 64-bit, with this processor:
PROCESSOR_ARCHITECTURE=AMD64
PROCESSOR_IDENTIFIER=Intel64 Family 6 Model 37 Stepping 5, GenuineIntel
It does not work on a Lenovo laptop running Window 7 64-bit, with this processor:
PROCESSOR_ARCHITECTURE=AMD64
PROCESSOR_IDENTIFIER=Intel64 Family 6 Model 58 Stepping 9, GenuineIntel
My question is: apart from the bitness are .dlls machine/processor type specific in some other way? (I know that the .dll files have to match the bitness of the machine, and that the JVM must also match the bitness of the .dll files)
Or in theory, if a .dll is 64-bit should it run on EVERY 64-bit machine that is using a 64-bit JVM?
apart from the bitness are .dlls machine/processor type specific in some other way?
Very much so. Any compiled binary meant to run under an operating system is both processor and operating system specific, sometimes even down to specific versions of each.
Different processors - even in the same family, such as "x86" - can offer different instruction sets and capabilities. See https://en.wikipedia.org/wiki/X86_instruction_listings for the listing of different variations of just x86 instruction sets and capabilities. If a compiled binary uses a specific instruction, it won't run on a processor that doesn't implement that instruction. For example, if a binary is compiled to use SSE3 instructions, it won't run on processors that don't implement SSE3.
And it's not just limited to hardware, either. Operating system specifics matter, too, literally for starters because the operating system is what starts the running process. So the binary needs to work under the conditions and in the environment of the operating system that started it. A binary designed to work under an operating system will also need to make calls to that operating system to interact with data, devices, or other processes. Different operating systems provide these capabilities in vastly different ways, even to the point of different versions of the same basic operating system doing so in incompatible ways.
And binaries that aren't designed to run under an operating system have to provide very hardware-specific capabilities - ever notice how many device drivers any operating system has? And this excludes any shared object or DLL because by definition they are already designed to run under an operating system.
Or in theory, if a .dll is 64-bit should it run on EVERY 64-bit
machine that is using a 64-bit JVM?
It should be clear by now that the answer is "Not even close".
I have two questions:
I found a blog entry saying that DisablePagingExecutive should be set when using xperf:
http://blogs.msdn.com/b/pigscanfly/archive/2009/08/06/stack-walking-in-xperf.aspx
Disable Paging Executive
In order for tracing to work on 64-bit Windows you need to set the DisablePagingExecutive registry key. This tells the operating system not to page kernel mode drivers and system code to disk, which is a prerequisite for getting 64-bit call stacks using xperf, because 64-bit stack walking depends on metadata in the executable images, and in some situations the xperf stack walk code is not allowed to touch paged out pages.
Is this required to collect xperf data for a 32-bit application running on 64-bit Windows?
When collecting data with xperf for a 32-bit process on a 64-bit OS, should I be using the x86 or x64 version?
You should set DisablePagingExecutive to 1 and use the 64-bit version of WPT if you are using 64-bit Windows.
The 64-bit version of WPT is needed because the 32-bit version won't even install on 64-bit Windows.
Setting DisablePagingExecutive to 1 is needed because even a 32-bit program can make calls into the 64-bit kernel. In order to get full call stacks that include the kernel code you need to lock the metadata into non-pageable memory, which is what setting DisablePagingExecutive does.
Just set it. It doesn't cost much (it uses a bit more memory) and if you set it you don't need to worry about it.
And the simplest way to set it is to use a trace recording UI. wprui is one choice (it ships with the Windows Performance Toolkit) but I prefer UIforETW. Details at https://randomascii.wordpress.com/2015/09/24/etw-central/
According to a Microsoft blog article, it seems disabling paging executive is no longer required as of Windows 8 / 2012 to obtain complete stacks in a WPT trace.
When explaining the process for disabling paging executive, it specifically states:
Does [disabling paging executive] need to be done in Windows Server 2012 or 32-bit/64-bit
Windows 8? No.
I found this after reading another (several years old) article which stated that on starting WPR for the first time, it should prompt you to disable paging executive if it isn't already. I wasn't getting this prompt, despite the DisablePagingExecutive registry key being set to zero, so I did some digging and found the above info.
The articled is dated 2012, so those were the latest Windows releases at the time. Presumably this has carried forward in later releases (I was running WPR on Server 2016 and was not prompted).
You must use the 64Bit Version of WPT and you must set the DisablePagingExecute to 1.
Is it possible to run an application on a 64 bit Weblogic 10.3.2 Server instance with a 32 bit JDK?
The reason for me to doing this is getting an exceptions while running my program using 64 bit JDK.
UCFWin32JNI.dll: Can't load IA 32-bit .dll on a AMD 64-bit platform
The error is gone when using 32 bit JDK.
If it is possible, then how?
Thanks!
A 32-bit version of a library cannot be loaded and used by a 64-bit JVM, and vice versa.
Moreover, UCFWin32JNI.dll does not appear to be a WebLogic library at all. In fact, it appears to be a library from Documentum. You ought to be looking for a 64-bit version of that library (if it is available) as it appears to be a 32-bit version going by the name and the error message produced. Finally, you'll need to place the 64-bit version in one of the directories constituting java.library.path.
No problems at all running a 32bit JVM on a 64bit platform. In fact, for some applications it can actually be more efficient, due to the fact that certain data types are innately larger on a 64bit JVM (ints I think are an example of this from memory)
A 64bit JVM provides all sorts of advantages for an application requiring access to a larger heap, but there's no harm at all in running a 32bit JVM.
Would anyone please give me ideas about forcing 64 bit jvm to run as 32-bit jvm?
I need to write a jse desktop application for bluetooth connection. For that i need to implement Bluecove jar . It has 32-bit files only. So i included -D32 under VM arguments in eclipse pulsar. But still i am getting the same error that displayed before adding the argument: bluecove_x64.dll missing. I tried with -d32, and it showed me "unrecognized option: d32".
And it seems like i should install a 32-bit jvm that would run on 64-bit os. So, can anyone please tell me what exactly should i install? Java SDK in 32-bit or Eclipse software?
Thanks in advance!
Switching modes is only possible on Solaris. A JVM is either 64bit or 32bit, except on Solaris where both run modes are available in a single JVM.
But anyway, if you don't need more than 4Gig Ram, install the 32bit JVM also on 64bit Systems, because it is 10-15% faster and needs less memory.
First, install a 32-bit JVM. (I suppose this is under Windows).
Then in Eclipse, open the Preferences panel, and go to Java -> Installed JRE's.
Click Search, tell it to search your harddisk.
Wait.
You should now see both your original 64-bit JVM and your new 32-bit JVM in the list. Put the checkmark on the 32-bit JVM instead of the 64-bit JVM. Click OK.
You should now use a 32-bit JVM in Eclipse, which should be compatible with the library you have.