I have a very strange behavior via IE Driver 32 bit. For example I input "Hello! My name is Maria." But result is:
I've tried to use 64 bit, but the result is the same.
Has anyone else come across this problem?
My environment: Windows 10, C#+SpecFlow, WebDriver.IEDriverServer.win32, IE(11.608).
For me downgrading of IEDriverServer on version 3.2.0 solved problem.
Related
I installed Lutris with Wine to play games on my Linux computer but I'm encountering an issue with Esync which is required to play the game I want. So I tried everything on both those links : https://github.com/lutris/docs/blob/master/HowToEsync.md and https://github.com/zfigura/wine/blob/esync/README.esync (I am in the systemd case but I also tried the other one). But whatever I do ulimit -Hn will always return 4096 and Lutris won't enable Esync. Does some have an idea on how to fix this ? I don't know what else to do about that. Thanks.
Using printf format in for numbers which will work fine:
printf ("\r\n <%s>\t AmountOfMalloc %'.ld", HostName ,GetMalloc ()) ;
Output is like this, which is fine:
AmountOfMalloc 17.220.149.424
Calling the same app remote via mrsh in a script will cause no number format like this:
AmountOfMalloc 17220149424
Envirenment is Suse Linux Enterprise Server 15 sp2 in VMware Workstation 15.5.7 on Windows 10 ltsc 2019, 4 cores, 6GB ram.
Has someone expierienced this issue and a possible solution?
The difference is caused by different environment locale settings.
You can see the settings that are applied when the program runs the way you want by running locale command. It will output several lines for e.g. money and number format settings, but usually they all have the same value, such as "en_US.UTF-8".
Easiest way to apply the setting to your remotely run command is to prefix the line like this:
LC_ALL=en_US.UTF-8 /path/to/program
From the examples you provide, the locale you want is probably different than en_US.UTF-8, so use the value you get from locale.
Thanks a lot, locale was the problem. Did not see any reason why,
Adding the following to the c source before printf works fine:
setlocale ( LC_NUMERIC, "de_DE.UTF-8" ) ;
setlocale ( LC_ALL, "de_DE.UTF-8" ) ;
Thanks.
I have an application that uses libnl. It can use either versions (1 or 3), and during configure it tries first to use ibnl3 and fallback to libnl-1 if libnl3 was not found.
My app uses another library that also uses libnl.
The problem is that I only have libnl1-dev on my machine so my app must use it.
But the library that I use uses libnl3 (was installed with yum i guess it's static linked)
so i have both version and my application crashes!!
here are some prints
ldd myapp.so|grep libnl
libnl.so.1 => /lib64/libnl.so.1 (0x00007fda33eb5000)
libnl-route-3.so.200 => /lib64/libnl-route-3.so.200 (0x00007fda32a3d000)
libnl-3.so.200 => /lib64/libnl-3.so.200 (0x00007fda3281b000)
yum list|grep libnl
libnl.x86_64 1.1.4-3.el7
libnl-devel.x86_64 1.1.4-3.el7
libnl3.x86_64 3.2.28-2.el7
libnl3-cli.x86_64 3.2.28-2.el7
libnl.i686 1.1.4-3.el7
libnl-devel.i686 1.1.4-3.el7
libnl3.i686 3.2.28-2.el7
libnl3-cli.i686 3.2.28-2.el7
if in install libnl3-dev it fixes the issue
is there another solution?
if I install libnl3-dev it fixes the issue is there another solution?
There are other solutions, but the bottom line is that you can only have libnl.so.1 or libnl-3.so.200, but not both.
Fixing this by "going all in on libnl-3" is the simplest solution.
The alternative is to "go all on on libnl-1", which means rebuilding anything that requires libnl-3 from source (against libnl-1). This is assuming that your other dependencies can be built against libnl-1 at all (which is by no means guaranteed).
I am programming in Windows 7 64 bits with VS 2013.
I already have a code which was developed in Linux 64 bits. That code is full of sprintf() functions.
Now, I run that code in Windows 64 bits, it shows alert windows.
At first, I tried sprintf, and it shows use sprintf_s. So I changed.
After change my code window shows this error.
Program : ...visual studio
2012\Project\IIS_Partial\Debug\IIS_Partial.exe
File : f\dd\vctools\crt_bld\self_x86\crt\src\vsprintf.c
Line : 233
Expression : format != NULL
For information on how your program can cause an assertion
failure, see the Visual C++ documentation on asserts.
(Press retry to debug the application)
Actually my code is made in C. Why this refers C++.
And I could even debug, because pressing the "debug" button directly goes to this error window. Are there any clues?
Thanks for reading:D
It was just a simple configuration matter.
Basically Microsoft Visual Studio 2012 is compiling as 32 bits.
So if someone want to run a source code in 64 bits, has to change options.
right click on [solution] -> [properties] -> [Configuration] -> [Configuration Manager](right upper corner of window) -> [Active Solution Platform] flow Menu -> -> upper is 'x64' and lower is 'Win32'. check the lower box.
and confirm. Now it builds in 64 bits environment.
Original Explanation from Microsoft Official site is :
http://msdn.microsoft.com/en-us/library/vstudio/9yb4317s.aspx
Which one is better in following aspects to get OS name, OS version in windows -
time in getting information
compatibility in all windows OS like xp, vista and higher
systeminfo or wmic command? I wanted to avoid the use of OSVersionInfoEx in C as one has to hardcode the marketing name detection and will add to maintenance work if new flavour of windows gets introduced. Please share your opinion.
GetVersionEx - You can't get any faster than this for getting a basic os version number. But you are right, you won't be able to map newer versions of the OS to the correct string. Have you considered just doing this:
OSVERSIONINFOEX version = {};
char szOS[MAX_OS_LENGTH];
version.dwOSVersionInfoSize = sizeof(version);
GetVersionEx((OSVERSIONINFO*)&version);
if (MyFunctionToMapVersionToString(&version, szOS) == false)
{
sprintf(szOS, "Microsoft Windows %d.%d", version.dwMajorVersion, version.dwMinorVersion);
}
WMI - A bit more code to write. But you could likely just do this at app startup (or when it's needed) and cache the result if the information is needed again. It's not like the operating system product name will change after the app has queried for it once. :) As to backwards compatibility, I'm sure it work fine on older operating systems... but you are going to test it before shipping it to the customer, right?
If you want an undocumented way, there is a registry key that has exactly what you want in it:
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion ("ProductName")