Here is an example program that illustrates my problem, it can be compiled using FlatAssembler without using a linker:
format PE console
entry start
include 'win32a.inc'
section '.text' code executable
start:
mov dword [esp],_output1
call [printf]
mov dword [esp+4],first
mov dword [esp],_input
call [scanf]
mov dword [esp],_output2
call [printf]
mov dword [esp+4],second
mov dword [esp],_input
call [scanf]
finit
fld dword [first]
fabs
fld dword [second]
fxch
fld1
fxch
fyl2x
fldl2e
fdivp st1,st0
fmulp st1,st0
fldl2e
fmulp st1,st0
fld1
fscale
fxch
fld1
fxch
fprem
f2xm1
faddp st1,st0
fmulp st1,st0
fstp dword [result]
fld dword [result]
fst qword [esp+4]
mov dword [esp],_output
call [printf]
invoke system,_pause
invoke exit,0
_output1 db "Enter the first number: ",0
_output2 db "Enter the second number: ",0
_input db "%f",0
_pause db "PAUSE",0
_output db "The first number to the power of the second number is: %f.",10,0
section '.rdata' readable writable
result dd ?
first dd ?
second dd ?
section '.idata' data readable import
library msvcrt,'msvcrt.dll'
import msvcrt,printf,'printf',system,'system',exit,'exit',scanf,'scanf'
So, the expected output is, of course, something like this:
Enter the first number: -2.5
Enter the second number: -2
The first number to the power of the second number is: 0.16
And that's the output I indeed get if I run that program on Windows 10. However, if I try to run that program on WINE on Oracle Linux, the output I get is:
000f:fixme:service:scmdatabase_autostart_services Auto-start service L"MountMgr" failed to start: 2
000f:fixme:service:scmdatabase_autostart_services Auto-start service L"WineBus" failed to start: 2
wine: Bad EXE format for Z:\home\teo.samarzija\Documents\Assembly\debug.exe.
Any idea what's going on?
I've done a little research, and I can't find any reference confirming that _printf and _scanf are even implemented in WINE's MSVCRT. However, I am not sure that's the problem, and, if it is a problem, that that's the only problem.
However, if I try to run that program on WINE on Oracle Linux, the
output I get is:
000f:fixme:service:scmdatabase_autostart_services Auto-start service L"MountMgr" failed to start: 2
000f:fixme:service:scmdatabase_autostart_services Auto-start service L"WineBus" failed to start: 2
wine: Bad EXE format for Z:\home\teo.samarzija\Documents\Assembly\debug.exe.
A "Bad EXE format" error is something different entirely. It doesn't imply that the problem is a missing imported function. The loader never got that far. It wasn't even able to read your binary. This is very likely caused by a bitness mismatch. For example, trying to run a 64-bit application on a 32-bit system.
Aside from this problem, it is worth pointing out that your attempted use of C runtime library functions is inherently non-portable. It might work, if Wine (or whatever other runtime environment) provides a function with an identical signature, but it very likely won't.
I suppose I should further clarify, since calling a standard C runtime library function "non-portable" may raise a few eyebrows. These functions are portable at the source-code level, but not at the binary level. Even without the added complexity of Wine, the C runtime library functions are non-portable, as Microsoft's CRT is versioned—you have to link to the appropriate version and have that DLL available at runtime, or your application will not work.
This exact problem is why Windows provides wrappers for these standard functions as part of the basic platform API, which is universally available. If you want to be fully portable to all implementations of the Win32 environment, and you aren't linking in your own copy of the C runtime library, then you should call these functions instead.
The Win32 version of the sprintf function is wsprintf. It has the same interface as sprintf, so you can call it the same way, as a drop-in replacement. In fact, although you shouldn't rely on this, it is implemented by Windows as a simple wrapper around the sprintf version provided by the local copy of the C runtime libraries.
If you want a version to which you can pass an argument list (a la vsprintf), then you can call wvsprintf.
Note that, unlike most of the Windows API functions, these functions use the __cdecl calling convention, not the __stdcall calling convention. Make sure that you are adhering to that in your assembly code. In short, that means passing arguments from right-to-left and cleaning up the stack at the call site.
Microsoft has, however, deprecated these functions, as they aren't entirely safe (buffer overflows and etc. are possible). As replacements, they offer the functions in the StrSafe.h header. These functions come in two variants: those which take a count of bytes (Cb) and those which take a count of characters (Cch). The relevant ones to this discussion would be either StringCbPrintfA or StringCchPrintfA. These are trickier to use from assembly language, however, because they're meant to be used inline by simply including the StrSafe.h header file. You can use them in library form, but then you'll need to pass the corresponding StrSafe.lib stubs to the linker. Note that linking to this library means your application will only run on Windows XP with SP2 or later.
This gets you halfway there. You are actually trying to call printf, rather than sprintf. The gap, of course, is getting the formatted string written to the console. Once you have the formatted string (generated by wsprintf, StringCchPrintfA, or whatever), that can be accomplished by calling the WriteConsole function, which is the Win32 API for writing output to the console window. If you want STDOUT, then you need to open that handle first with GetStdHandle(STD_OUTPUT_HANDLE).
Anyway, I got the answer:
https://www.linuxquestions.org/questions/linux-general-1/can%27t-install-wine-on-64-bit-oracle-linux-4175655895/page2.html#post6012838
In short, on 64-bit Oracle Linux, WINE needs to be compiled from source to work properly.
I want to call define a function in asm file and call this function from a Cpp file/function. Also I have to compile the project on 64-bit platform.
Please help me in doing that as I don't have much idea about assembly code. Any help will be appreciated.
Thanks
This file is an ASM file from ffdshow that performs some work with CPUID. It's both x64 and x86. YASM is used to assemble it.
What most people do today is not write ASM code but use intrinsic functions. There are intrinsic functions for all SSE/AVX/etc. even for low level ring0 instructions. Intrinsic functions allow the compiler to do extra optimizations and are shared between 32 and 64bit builds.
A code snippet would help, but if you want to place inline assembly within a regular C++ function, you can do that by placing it in an asm block like this:
void myClass::myFunc() {
// cpp code
int a = 0;
// ...
// asm code
__asm {
mov eax, ebx;
// ...
};
// more cpp code
// ...
}
I was writing a kernel module that will check some thing in VFS . In this module, I need to use the kernel API "putname" which is defined as:
#ifdef CONFIG_AUDITSYSCALL
void putname(const char *name)
{
if (unlikely(!audit_dummy_context()))
audit_putname(name);
else
__putname(name);
}
EXPORT_SYMBOL(putname);
When I complied it in Fedora 18 with kernel 3.6.10, Everything is OK, the module works fine, but when I switch it to kernel 3.11.4. The complier gave me a warnning "putname is undefined", When I replace "putname" with "__putname", the kernel module can be complied but when it was running, something will go wrong. the backtrace shows that it was in __putname. Is there anybody can help me on this issue?
Thanks
See the commit #91a27b2a756784714e924e5e854b919273082d26 from Jeff:
This patchset converts the getname()/putname() interfaces to return a struct instead of a string. For now, the struct just tracks the string in kernel space and the original userland pointer for it.
The interface was changed right after the v3.6. So you have to rework your code taking this change into account.
As we've started to work with iOS7 - and facing some issue during coding - i.e. how we can compare iPhone5 and iPhone 5S - So that we can check either the system is 32bit or 64bit and can use variables accordingly.
If you want to do this via compile time conditionals, there's a new "__arm64__" conditonal defined that is now available for 64-bit compiled code.
Presumably "__arm__" is what gets defined for 32-bit device code.
You'll also likely notice there's a new available architecture in Xcode alongside "armv6, armv7 and armv7s", that being "arm64".
So you could do something like this:
#ifdef __arm64__
NSLog( #"we're running 64-bit");
else
NSLog( #"32-bit iphone code");
#endif
I am making SYSTEM CALL for linux 2.6.39 kernel.
I have completed all the edits in the files. Now When i am trying to compile the kernel it is showing this error :
error: stdio.h: No such file or directory
If i remove stdio.h, Will the system call work ???
My code is
#include<stdio.h>
#include <linux/linkage.h>
asmlinkage long sys_atvfcfs(int at[], int bt[], int n)
{
int i=0;
int j,t,wt[n],sum,q;
float avgwt;
for(j=i+1;j<n;j++)
{
if(at[i]>at[j])
{
t=at[i];
at[i]=at[j];
at[j]=t;
q=bt[i];
bt[i]=bt[j];
bt[j]=q;
}
}
wt[0]=0;
sum=0;
for(i=0;i<n-1;i++)
{
wt[i+1]=wt[i]+bt[i];
sum=sum+(wt[i+1]-at[i]);
}
avgwt=sum/n;
return avgwt;
}
I have no idea what your system call is supposed to do, but it doesn't call any functions declared in stdio.h. (It doesn't call any functions at all, in fact.) So it should be safe to remove that line.
stdio.h is a C library header. It's available in ordinary C programs, but a kernel is different. A kernel is self-contained; it can't depend on userspace libraries, because userspace libraries depend on the kernel to do their work. Instead, the kernel has its own internal library of useful functions that you'll want to learn about if you're doing kernel development.
I do'nt see any io functions used in your code, so you don't need to include stdio.h
You don't need stdio.h in kernel programming. If you need to print something, use printk instead of printf.