digitalmars.D - Linking COFF and OMF
- Dmitry Olshansky <dmitry.olsh gmail.com> Feb 20 2011
- Trass3r <un known.com> Feb 20 2011
- Don <nospam nospam.com> Feb 20 2011
- Trass3r <un known.com> Feb 21 2011
- Don <nospam nospam.com> Feb 21 2011
- Trass3r <un known.com> Feb 21 2011
- %u <wfunction hotmail.com> Feb 21 2011
- Rainer Schuetze <r.sagitario gmx.de> Feb 22 2011
- %u <wfunction hotmail.com> Feb 22 2011
- dennis luehring <dl.soluz gmx.net> Feb 23 2011
- Trass3r <un known.com> Feb 23 2011
- Adam Ruppe <destructionator gmail.com> Feb 23 2011
- dennis luehring <dl.soluz gmx.net> Feb 23 2011
- Dmitry Olshansky <dmitry.olsh gmail.com> Feb 23 2011
- Trass3r <un known.com> Feb 23 2011
- %u <wfunction hotmail.com> Feb 28 2011
- Trass3r <un known.com> Mar 01 2011
- %u <wfunction hotmail.com> Mar 01 2011
- dennis luehring <dl.soluz gmx.net> Feb 23 2011
- Trass3r <un known.com> Feb 23 2011
- dennis luehring <dl.soluz gmx.net> Feb 23 2011
- Trass3r <un known.com> Feb 21 2011
- Andrej Mitrovic <andrej.mitrovich gmail.com> Feb 23 2011
I just took a stab at linking together different object formats with
UniLink.
Well, it just works(tm). So I may suggest to anyone having to link with
precompiled COFF static libs on windows to try it out.
For starters I just replaced most of my kernel32.lib, shell32.lib etc
with Microsoft SDK latest COFF import lib variants and
then built and linked winsamp.d from the DMD examples dir. Of course,
that broke optlink linkage.
Then I tried it with static libs, so I produced simplistic static lib
with MinGW gcc:
#include <stdio.h>
int AddInt(int i1, int i2)
{
return i1 + i2;
}
void PrintInt(int a)
{
printf("%d\n",a);
}
and linked with this module:
import std.stdio;
extern(C) int AddInt(int a,int b);
extern(C) int PrintInt(int a);
void main(){
assert(AddInt(3,5) == 8);
PrintInt(42);
writeln("Works?");
}
All passed as expected. (It took renaming lib from *.a to *.lib but
that's it!)
I guess it linked printf with DMC's printf in snn.lib though,
so there might be some problems with foreign RTLs when one goes too far.
P.S. I know I sound like a freaking promoter ;)
--
Dmitry Olshansky
Feb 20 2011
I guess it linked printf with DMC's printf in snn.lib though, so there might be some problems with foreign RTLs when one goes too far.
Can we replace snn with the other RTL?
Feb 20 2011
Trass3r wrote:I guess it linked printf with DMC's printf in snn.lib though, so there might be some problems with foreign RTLs when one goes too far.
Can we replace snn with the other RTL?
In 2.052 several of the most complicated dependencies on snn.lib (those relating to exception handling) were removed. I don't know how many more DMC-specific ones there are, but using another snn.lib might be possible now.
Feb 20 2011
In 2.052 several of the most complicated dependencies on snn.lib (those relating to exception handling) were removed. I don't know how many more DMC-specific ones there are, but using another snn.lib might be possible now.
Compiled a hello world with empty snn.lib: OPTLINK (R) for Win32 Release 8.00.8 Copyright (C) Digital Mars 1989-2010 All rights reserved. http://www.digitalmars.com/ctg/optlink.html helloworld.obj(helloworld) Error 42: Symbol Undefined __acrtused_con C:\dmd\windows\bin\..\lib\phobos.lib(dmain2) Error 42: Symbol Undefined ___alloca C:\dmd\windows\bin\..\lib\phobos.lib(dmain2) Error 42: Symbol Undefined __except_list helloworld.obj(helloworld) Error 42: Symbol Undefined _fprintf C:\dmd\windows\bin\..\lib\phobos.lib(dmain2) Error 42: Symbol Undefined _wcslen C:\dmd\windows\bin\..\lib\phobos.lib(deh) Error 42: Symbol Undefined __tls_array C:\dmd\windows\bin\..\lib\phobos.lib(deh) Error 42: Symbol Undefined __tls_index C:\dmd\windows\bin\..\lib\phobos.lib(gc) Error 42: Symbol Undefined _memcpy C:\dmd\windows\bin\..\lib\phobos.lib(gc) Error 42: Symbol Undefined _malloc C:\dmd\windows\bin\..\lib\phobos.lib(memory) Error 42: Symbol Undefined __xi_a C:\dmd\windows\bin\..\lib\phobos.lib(memory) Error 42: Symbol Undefined __end C:\dmd\windows\bin\..\lib\phobos.lib(gcx) Error 42: Symbol Undefined _calloc C:\dmd\windows\bin\..\lib\phobos.lib(gcx) Error 42: Symbol Undefined _free C:\dmd\windows\bin\..\lib\phobos.lib(gcx) Error 42: Symbol Undefined _memset C:\dmd\windows\bin\..\lib\phobos.lib(object_) Error 42: Symbol Undefined _strlen C:\dmd\windows\bin\..\lib\phobos.lib(thread) Error 42: Symbol Undefined __beginthreadex C:\dmd\windows\bin\..\lib\phobos.lib(thread) Error 42: Symbol Undefined __tlsend C:\dmd\windows\bin\..\lib\phobos.lib(thread) Error 42: Symbol Undefined __tlsstart C:\dmd\windows\bin\..\lib\phobos.lib(object_) Error 42: Symbol Undefined _memcmp C:\dmd\windows\bin\..\lib\phobos.lib(gcx) Error 42: Symbol Undefined _memmove C:\dmd\windows\bin\..\lib\phobos.lib(gcx) Error 42: Symbol Undefined _realloc C:\dmd\windows\bin\..\lib\phobos.lib(regexp) Error 42: Symbol Undefined _printf C:\dmd\windows\bin\..\lib\phobos.lib(regexp) Error 42: Symbol Undefined _memchr C:\dmd\windows\bin\..\lib\phobos.lib(datetime) Error 42: Symbol Undefined _localtime C:\dmd\windows\bin\..\lib\phobos.lib(datetime) Error 42: Symbol Undefined _tzset C:\dmd\windows\bin\..\lib\phobos.lib(stdio) Error 42: Symbol Undefined __iob C:\dmd\windows\bin\..\lib\phobos.lib(monitor) Error 42: Symbol Undefined __assert C:\dmd\windows\bin\..\lib\phobos.lib(lifetime) Error 42: Symbol Undefined __LDIV C:\dmd\windows\bin\..\lib\phobos.lib(outbuffer) Error 42: Symbol Undefined __vsnprintf C:\dmd\windows\bin\..\lib\phobos.lib(stdio) Error 42: Symbol Undefined _fclose C:\dmd\windows\bin\..\lib\phobos.lib(stdio) Error 42: Symbol Undefined _tmpfile C:\dmd\windows\bin\..\lib\phobos.lib(stdio) Error 42: Symbol Undefined _ftell C:\dmd\windows\bin\..\lib\phobos.lib(stdio) Error 42: Symbol Undefined _fseek C:\dmd\windows\bin\..\lib\phobos.lib(exception) Error 42: Symbol Undefined _strerror C:\dmd\windows\bin\..\lib\phobos.lib(stdio) Error 42: Symbol Undefined _setmode C:\dmd\windows\bin\..\lib\phobos.lib(stdio) Error 42: Symbol Undefined ___fhnd_info C:\dmd\windows\bin\..\lib\phobos.lib(stdio) Error 42: Symbol Undefined _fread C:\dmd\windows\bin\..\lib\phobos.lib(stdio) Error 42: Symbol Undefined _fopen C:\dmd\windows\bin\..\lib\phobos.lib(conv) Error 42: Symbol Undefined __ULDIV C:\dmd\windows\bin\..\lib\phobos.lib(format) Error 42: Symbol Undefined ___pfloatfmt C:\dmd\windows\bin\..\lib\phobos.lib(errno) Error 42: Symbol Undefined _errno C:\dmd\windows\bin\..\lib\phobos.lib(stdio) Error 42: Symbol Undefined ___fp_unlock C:\dmd\windows\bin\..\lib\phobos.lib(stdio) Error 42: Symbol Undefined __fgetc_nlock C:\dmd\windows\bin\..\lib\phobos.lib(stdio) Error 42: Symbol Undefined __fgetwc_nlock C:\dmd\windows\bin\..\lib\phobos.lib(stdio) Error 42: Symbol Undefined ___fp_lock C:\dmd\windows\bin\..\lib\phobos.lib(ti_cfloat) Error 42: Symbol Undefined __Ccmp
Feb 21 2011
Trass3r wrote:In 2.052 several of the most complicated dependencies on snn.lib (those relating to exception handling) were removed. I don't know how many more DMC-specific ones there are, but using another snn.lib might be possible now.
Compiled a hello world with empty snn.lib:
That's pretty good. Almost all of those things are standard C. LDIV and UDIV could easily be eliminated. __except_list is a null asm label (it is FS:[0]). So the main problematic ones are: _xi_a , __acrtused_con, the __fp functions, and _CcmpOPTLINK (R) for Win32 Release 8.00.8 Copyright (C) Digital Mars 1989-2010 All rights reserved. http://www.digitalmars.com/ctg/optlink.html helloworld.obj(helloworld) Error 42: Symbol Undefined __acrtused_con C:\dmd\windows\bin\..\lib\phobos.lib(dmain2) Error 42: Symbol Undefined ___alloca C:\dmd\windows\bin\..\lib\phobos.lib(dmain2) Error 42: Symbol Undefined __except_list helloworld.obj(helloworld) Error 42: Symbol Undefined _fprintf C:\dmd\windows\bin\..\lib\phobos.lib(dmain2) Error 42: Symbol Undefined _wcslen C:\dmd\windows\bin\..\lib\phobos.lib(deh) Error 42: Symbol Undefined __tls_array C:\dmd\windows\bin\..\lib\phobos.lib(deh) Error 42: Symbol Undefined __tls_index C:\dmd\windows\bin\..\lib\phobos.lib(gc) Error 42: Symbol Undefined _memcpy C:\dmd\windows\bin\..\lib\phobos.lib(gc) Error 42: Symbol Undefined _malloc C:\dmd\windows\bin\..\lib\phobos.lib(memory) Error 42: Symbol Undefined __xi_a C:\dmd\windows\bin\..\lib\phobos.lib(memory) Error 42: Symbol Undefined __end C:\dmd\windows\bin\..\lib\phobos.lib(gcx) Error 42: Symbol Undefined _calloc C:\dmd\windows\bin\..\lib\phobos.lib(gcx) Error 42: Symbol Undefined _free C:\dmd\windows\bin\..\lib\phobos.lib(gcx) Error 42: Symbol Undefined _memset C:\dmd\windows\bin\..\lib\phobos.lib(object_) Error 42: Symbol Undefined _strlen C:\dmd\windows\bin\..\lib\phobos.lib(thread) Error 42: Symbol Undefined __beginthreadex C:\dmd\windows\bin\..\lib\phobos.lib(thread) Error 42: Symbol Undefined __tlsend C:\dmd\windows\bin\..\lib\phobos.lib(thread) Error 42: Symbol Undefined __tlsstart C:\dmd\windows\bin\..\lib\phobos.lib(object_) Error 42: Symbol Undefined _memcmp C:\dmd\windows\bin\..\lib\phobos.lib(gcx) Error 42: Symbol Undefined _memmove C:\dmd\windows\bin\..\lib\phobos.lib(gcx) Error 42: Symbol Undefined _realloc C:\dmd\windows\bin\..\lib\phobos.lib(regexp) Error 42: Symbol Undefined _printf C:\dmd\windows\bin\..\lib\phobos.lib(regexp) Error 42: Symbol Undefined _memchr C:\dmd\windows\bin\..\lib\phobos.lib(datetime) Error 42: Symbol Undefined _localtime C:\dmd\windows\bin\..\lib\phobos.lib(datetime) Error 42: Symbol Undefined _tzset C:\dmd\windows\bin\..\lib\phobos.lib(stdio) Error 42: Symbol Undefined __iob C:\dmd\windows\bin\..\lib\phobos.lib(monitor) Error 42: Symbol Undefined __assert C:\dmd\windows\bin\..\lib\phobos.lib(lifetime) Error 42: Symbol Undefined __LDIV C:\dmd\windows\bin\..\lib\phobos.lib(outbuffer) Error 42: Symbol Undefined __vsnprintf C:\dmd\windows\bin\..\lib\phobos.lib(stdio) Error 42: Symbol Undefined _fclose C:\dmd\windows\bin\..\lib\phobos.lib(stdio) Error 42: Symbol Undefined _tmpfile C:\dmd\windows\bin\..\lib\phobos.lib(stdio) Error 42: Symbol Undefined _ftell C:\dmd\windows\bin\..\lib\phobos.lib(stdio) Error 42: Symbol Undefined _fseek C:\dmd\windows\bin\..\lib\phobos.lib(exception) Error 42: Symbol Undefined _strerror C:\dmd\windows\bin\..\lib\phobos.lib(stdio) Error 42: Symbol Undefined _setmode C:\dmd\windows\bin\..\lib\phobos.lib(stdio) Error 42: Symbol Undefined ___fhnd_info C:\dmd\windows\bin\..\lib\phobos.lib(stdio) Error 42: Symbol Undefined _fread C:\dmd\windows\bin\..\lib\phobos.lib(stdio) Error 42: Symbol Undefined _fopen C:\dmd\windows\bin\..\lib\phobos.lib(conv) Error 42: Symbol Undefined __ULDIV C:\dmd\windows\bin\..\lib\phobos.lib(format) Error 42: Symbol Undefined ___pfloatfmt C:\dmd\windows\bin\..\lib\phobos.lib(errno) Error 42: Symbol Undefined _errno C:\dmd\windows\bin\..\lib\phobos.lib(stdio) Error 42: Symbol Undefined ___fp_unlock C:\dmd\windows\bin\..\lib\phobos.lib(stdio) Error 42: Symbol Undefined __fgetc_nlock C:\dmd\windows\bin\..\lib\phobos.lib(stdio) Error 42: Symbol Undefined __fgetwc_nlock C:\dmd\windows\bin\..\lib\phobos.lib(stdio) Error 42: Symbol Undefined ___fp_lock C:\dmd\windows\bin\..\lib\phobos.lib(ti_cfloat) Error 42: Symbol Undefined __Ccmp
Feb 21 2011
Trass3r <un known.com> Don Wrote:That's pretty good. Almost all of those things are standard C. LDIV and UDIV could easily be eliminated. __except_list is a null asm label (it is FS:[0]). So the main problematic ones are: _xi_a , __acrtused_con, the __fp functions, and _Ccmp
Yep, they need to be taken care of anyway to support 64Bit on Windoze, some of them are even written in asm. Member ..\core32\cinit.asm Offset 0x700 __argc _errno __argv __xi_a Member llmath.asm Offset 0x7E540 __LCMP __LDIV __LMUL __ULDIV Member ..\win32\constart.c Offset 0x5B280 BSS __acrtused_con
Feb 21 2011
That's pretty good. Almost all of those things are standard C. LDIV and UDIV could easily be eliminated. __except_list is a null asm label (it is FS:[0]). So the main problematic ones are: _xi_a , __acrtused_con, the __fp functions, and _Ccmp
So how to tackle that?
I'm really glad that this issue is being looked into. I've literally wasted days (if not a few weeks) getting another to work instead of SNN.lib, and I think that the ultimate culprit that prevented things from working was _xi_a. I couldn't figure out how to solve it; I'm not sure if it was the root cause, but I think it interfered with thread-static data, and/or the garbage collector. What does _xi_a even do? Is it anything more than just a marker inside the executable?
Feb 21 2011
%u wrote:What does _xi_a even do? Is it anything more than just a marker inside the executable?
have you seen this page: http://wiki.osdev.org/C_PlusPlus#Visual_C.2B.2B ? I think dmc is pretty much in line with it. You can also find these sections in the map files generated when compiling a D file with dmd.
Feb 22 2011
What does _xi_a even do? Is it anything more than just a marker inside the executable?
have you seen this page:
I think dmc is pretty much in line with it. You can also find these
:O no, I hadn't! That's great information; thanks!
Feb 22 2011
Am 22.02.2011 05:54, schrieb %u:That's pretty good. Almost all of those things are standard C. LDIV and UDIV could easily be eliminated. __except_list is a null asm label (it is FS:[0]). So the main problematic ones are: _xi_a , __acrtused_con, the __fp functions, and _Ccmp
So how to tackle that?
I'm really glad that this issue is being looked into. I've literally wasted days (if not a few weeks) getting another to work instead of SNN.lib, and I think that the ultimate culprit that prevented things from working was _xi_a. I couldn't figure out how to solve it; I'm not sure if it was the root cause, but I think it interfered with thread-static data, and/or the garbage collector. What does _xi_a even do? Is it anything more than just a marker inside the executable?
i don't if the source of snn.lib is available - is it? but the new ida freeware version 5 (http://www.hex-rays.com/idapro/idadownfreeware.htm) is very nice for the lib-analysis (core32\cinit.asm)
Feb 23 2011
dennis luehring Wrote:i don't if the source of snn.lib is available - is it?
Don't think so, that's dmc land.
Feb 23 2011
dennis luehring wrote:i don't if the source of snn.lib is available - is it?
The complete source to DMC and it's libraries are available in the purchased development kit.
Feb 23 2011
Am 22.02.2011 05:54, schrieb %u:That's pretty good. Almost all of those things are standard C. LDIV and UDIV could easily be eliminated. __except_list is a null asm label (it is FS:[0]). So the main problematic ones are: _xi_a , __acrtused_con, the __fp functions, and _Ccmp
So how to tackle that?
I'm really glad that this issue is being looked into. I've literally wasted days (if not a few weeks) getting another to work instead of SNN.lib, and I think that the ultimate culprit that prevented things from working was _xi_a. I couldn't figure out how to solve it; I'm not sure if it was the root cause, but I think it interfered with thread-static data, and/or the garbage collector. What does _xi_a even do? Is it anything more than just a marker inside the executable?
some light in the darkness... http://www.nynaeve.net/?p=44
Feb 23 2011
On 22.02.2011 7:54, %u wrote:That's pretty good. Almost all of those things are standard C. LDIV and UDIV could easily be eliminated. __except_list is a null asm label (it is FS:[0]). So the main problematic ones are: _xi_a , __acrtused_con, the __fp functions, and _Ccmp
wasted days (if not a few weeks) getting another to work instead of SNN.lib, and I think that the ultimate culprit that prevented things from working was _xi_a. I couldn't figure out how to solve it; I'm not sure if it was the root cause, but I think it interfered with thread-static data, and/or the garbage collector. What does _xi_a even do? Is it anything more than just a marker inside the executable?
Inspired by your works, I wasted best part of two hours and managed the following: replaced snn.lib with dummy one, for now I placed _acrt_used symbol there which happens to be weird 32bit integer, in fact. rebuild C part of druntime with MS C compiler into druntime_c.lib (that's MS COFF lib all right) rebuild the D part of druntime -> druntime.lib (that's OMF objects, they can't sit together) phobos actually builds as usual though now it lacks parts that were in druntime_c.lib then I linked simple program with MSVCRT lib and got Error: No entry point simple.d being: import core.stdc.stdio; void main(){ printf("Holly crap!\n"); } Some google-fu later I forcibly dragged mainCRTstartup symbol in, that's where is C runtime entry point for MSVCRT. I went like this: ulink simple.obj -i_mainCRTStartup druntime_c.lib phobos.lib Error: Unresolved external '__tlsend' referenced from 'C:\ulink\phobos.lib|thread.d' Error: Unresolved external '__tlsstart' referenced from 'C:\ulink\phobos.lib|thread.d' Error: Unresolved external '__LDIV ' referenced from 'C:\ulink\phobos.lib|thread.d' Error: Unresolved external '__xi_a' referenced from 'C:\ulink\phobos.lib|memory.d' Error: Unresolved external '___alloca' referenced from 'C:\ulink\phobos.lib|dmain2.d' that's where I stopped, technically it might still be attainable. What I gather is that windows DMD itself emits direct references on __LDIV, __alloca and friends found in snn. Maybe we can get out by writing simple thunk lib to replace snn.lib that maps these to MS runtime analogs if any. From druntime source I get an idea that __tlsstart, __tlsend are markers emitted by DMC dealing with them and TLS in general would be trickier ;) -- Dmitry Olshansky
Feb 23 2011
Dmitry Olshansky Wrote:that's where I stopped, technically it might still be attainable. What I gather is that windows DMD itself emits direct references on __LDIV, __alloca and friends found in snn. Maybe we can get out by writing simple thunk lib to replace snn.lib that maps these to MS runtime analogs if any. From druntime source I get an idea that __tlsstart, __tlsend are markers emitted by DMC dealing with them and TLS in general would be trickier ;)
Nice work so far :) Shouldn't something like alloca be available in VCRT as well?
Feb 23 2011
So I continued my quest to remove the SNN.lib dependency (and instead depend on MSVCRT.dll), and ran into a Heisenbug that I think might relate to TLS. Basically, the bug shows up only if Visual Studio isn't attached to the program, and it only happens when the program is exiting. (!) Would anyone be willing to help me figure this out? I feel like I'm SOOOO close and yet so far! :( I didn't attach the files, but I could definitely write up a set of detailed instructions saying what I did. Is anyone interested? It seems to me like if we can only fix this one error, we should be done with porting druntime to SNN.lib, and then we can focus on porting higher-level things like std.stdio (which should be much more straightforward). Anyone interested?
Feb 28 2011
what's the error?
I get an access violation at (or sometimes around) the statement ModuleInfo* m = _moduleinfo_tlsdtors[i]; inside _moduleTlsDtor() in object_.d. My entire code for the main file is below (although there's obviously more to the process, like the .obj files, a few other changes, etc.): ------------------------------------------------------------ import core.stdc.wchar_ : wprintf; import core.runtime : Runtime; pragma(lib, "msvcrt.lib"); pragma(startaddress, mainCRTStartup); extern (C) { //Is this right? What does it even do? static __gshared uint _acrtused_con = 0x00009876; int main(int argc, char** argv); //in dmain2.d } //Just to avoid bringing in Phobos here... unsafe though void writefln(S...)(in wchar[] format, S args) { wprintf(format.ptr, args); wprintf("\n"); } extern (Windows) int mainCRTStartup() { Runtime.initialize(); scope(exit) Runtime.terminate(); // << ERROR here return main(0, null); } int main(string[] args) { writefln("%u", args.length); return 0; } ------------------------------------------------------------- If I comment out the line with the error, it runs fine *inside* the Visual Studio debugger, but crashes outside (at a similar place)... can't figure it out, and I think you might need to actually try it to see what I mean. Any ideas?
Mar 01 2011
Am 21.02.2011 15:26, schrieb Don:Trass3r wrote:In 2.052 several of the most complicated dependencies on snn.lib (those relating to exception handling) were removed. I don't know how many more DMC-specific ones there are, but using another snn.lib might be possible now.
Compiled a hello world with empty snn.lib:
That's pretty good. Almost all of those things are standard C. LDIV and UDIV could easily be eliminated. __except_list is a null asm label (it is FS:[0]).
question out of curiosity - would it be a good idea (or technical solveable) to replace the snn.lib complete with D code?
Feb 23 2011
dennis luehring Wrote:question out of curiosity - would it be a good idea (or technical solveable) to replace the snn.lib complete with D code?
Doesn't make sense since you'd have to introduce the D runtime into C runtime code (remember that dmc also uses that runtime for compiling C code) Furthermore I expect it wouldn't technically work cause the D runtime itself requires a C runtime.
Feb 23 2011
Am 23.02.2011 12:56, schrieb Trass3r:dennis luehring Wrote:question out of curiosity - would it be a good idea (or technical solveable) to replace the snn.lib complete with D code?
Doesn't make sense since you'd have to introduce the D runtime into C runtime code (remember that dmc also uses that runtime for compiling C code) Furthermore I expect it wouldn't technically work cause the D runtime itself requires a C runtime.
introduce the D runtime into C runtime code
why? (except you want to use the existing C runtime code)I expect it wouldn't technically work cause the D runtime itself requires a C runtime.
ok maybe a bootstrap is needed - dmd/phobos links with snn.lib produced by dmc, and another compile/link run for dmd and phobos - with an D version of snn.lib i don't the big technical difficulty here - any special case? something that can't be done with D? do the WinApi needs some form of C-Runtime initalisation on Application-side? (i don't think so) - and the excecption-stuff is win-api based not c-runtime, or?
Feb 23 2011
That's pretty good. Almost all of those things are standard C. LDIV and UDIV could easily be eliminated. __except_list is a null asm label (it is FS:[0]). So the main problematic ones are: _xi_a , __acrtused_con, the __fp functions, and _Ccmp
So how to tackle that?
Feb 21 2011
On 2/23/11, dennis luehring <dl.soluz gmx.net> wrote:but the new ida freeware version 5
I did not know v5 went freeware. Fantastic, thanks.
Feb 23 2011