April 06, 2006 Re: std.date proposal | ||||
---|---|---|---|---|
| ||||
Posted in reply to Fredrik Olsson | Fredrik Olsson wrote: > Perhaps a better example: > Item[] itemsInRange(Item[] items, d_date start, d_date end) { > Item[] ret; > foreach (Item item; items) { > if (isInRange(item.date, start, end) > ret ~= item; > } > return ret; > } > > Introducing itemsBefore() and itemsAfter() could be done, but less code for the same functionality would be to simply send "infinity" to itemsInTange's start or end. And now it would be nice with a set standard for "what is infinity". You can use d_time.max and d_time.min. I also don't understand why use isInRange rather than < and >. > Best would be if the properties min and max could be made for typedefs, and maybe introduce your own, such as nad for "not a date". There's already a d_time_nan for just that purpose. |
April 06, 2006 Re: On processors for D | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | Walter Bright wrote: > Georg Wrede wrote: >> Walter Bright wrote: >> >>> At the start that D wasn't going to accommodate 16 bit processors for >>> very good reasons, there are 32 bit processors in wide use in the embedded market that do not have hardware floating point. There is no >>> reason to gratuitously not run on those systems. >> >> Ok, that was exactly the answer I thought I'd get. >> >> Currently, this issue is not entirely foreign to me. I'm delivering a HW + SW solution to a manufacturer of plastics processing machines, where my solution will supervise the process and alert an operator whenever the machine "wants hand-holding". >> >> For that purpose, the choice is between an 8-bit and a 16-bit processor. Very probably a PIC. (So no D here. :-), I'll end up doing it in C.) > > So, you're not even using a 32 bit processor, but a 16 bit design. I know for a fact that there are *new* embedded systems designs going on using 32 bit processors that don't have FPUs. True. I understand they are targeted to big manufacturers, who know exactly the use, and do large production runs. And where ASICs would be too expensive, considering the width of the task. (Set top boxes, automotive control subsystems, telecomms network equipment, etc.) Making significant inroads to those areas, however, may be asking for too much. The manufacturers are big corporations, they have an established (and massive) infrastructure already in place, and that is either directly or indirectly relying on C, whose track record is unparallelled. So for them to even glimpse at D, D would have to offer something significantly better for that domain. (Which (I'm sorry) I don't currently see.) >> Now, considering Moore, and the fact that the 80387 math coprocessor didn't have all too many transistors, the marginal price of math is plummeting. Especially compared with the minimum number of transistors needed for a (general purpose) 32-bit CPU. > > So why are you using a 16 bit design? I can guess - cost. And that's why embedded systems for 32 bit processors often don't have FPUs. Cost, where even a few cents matter. (Also power consumption.) The task is simple enough for an 8-bit processor to handle just fine. (In my case, the thing is mains-operated, and the CPU cost is negligible compared with the rest of the delivery, so my reason is just easier programming.) >> Also, since the purveyors of 32-bit processors are keen on showing the ease of use and versatility of their processors, it is likely that even if math is not on the chip, they at least deliver suitable libraries to emulate that in software. > > I have such a library (needed for the DOS-32 support). Although it works fine, it is 100 times slower than hardware floating point. Embedded CPUs are often strapped for speed, so why gratuitously require floating point? It should be much slower. Otherwise FPUs would not be popular. :-) Otoh, it doesn't slow down anything else, so in many cases the total performance hit is minor. And a good compiler/linker would in any case indluce only the actually used routines. You may even use this in combination with lookup tables, if profiling results show the need. (Why use FP hardware or libraries at all, is the same kind of question as why use automatic memory management! Right? One can get by without, but if it's there, why not use it.) >> Now, in the former case, math is either on-chip, or included in the libraries. In the latter, either we don't use math, or we make (or acquire) the necessary functions from other sources. > > Or design out unnecessary uses of floating point. For speed, of course. But for size, with D, it's not that simple. With the current size of "Hello World" (if done without C's printf), a basic FP library starts to feel small. >> The second use case worries me. (Possibly unduely?) D not being entirely decoupled from Phobos, at least creates an illusion of potential problems for "from-scratch" SW development for embedded HW. > > Phobos doesn't require floating point support from the processor unless one actually uses floating point in the application code. Turbo Pascal has had this since the '80s. You could turn a switch so that it automatically uses the FP library if float was used and the runtime computer didn't have an FPU. > I also really don't understand why anyone using D would require not using Phobos. What's the problem? I admit this is a "feelings based" thing with most people I've talked with. It seems that on embedded platforms, many expect to write all the needed code themselves. It's also felt (possibly unduely??) that Phobos (or whatever general Win+*nix standard library) is mostly useless in embedded applications. Of course, this may also be due to lack of information on their side? >> We do have to remember the reasons leading to choosing a 32-bit processor in the first place: if the process to be cotrolled is too complicated or otherwise needs more power than a 16-bit CPU can deliver, only then should one choose a 32-bit CPU. Now, at that time, it is likely that requirements for RAM, address space, speed, and other things are big enough that the inclusion of math (in HW or library) becomes minor. > > All I can say is I posed the same question to embedded systems people using 32 bit CPUs sans FPU, and they tell me the costs are not minor - either in money or power consumption. The world is going towards an increasing number of small and midsize companies entering the embedded arena. They typically would want to work with a single architecture, for obvious reasons. A CPU that contains math hardware which can be turned off when not needed (as well as other systems that can be powered off), seems to answer that kind of needs. I increasingly see CPU designers understanding this trend. --- To give a parallell (to explain my view here): There are many Linux distributions that are compiled with 386 as target. At the same time, their specs for memory, clock speed, etc. _in_practice_ rule out any machine not using recent Intel processors. I see this as a joke. Call this inconsistent specs. I'm discussing here so D would avoid this kind of inconsistencies. Insisting on not needing hardware FP is ok. But to legitimize that, one has to cater to scarce resources in other areas too. Conversely, not genuinely making the language usable in smaller environments, makes striving to independence of FPU not worth the effort and inconvenience. |
April 06, 2006 Re: On processors for D | ||||
---|---|---|---|---|
| ||||
Posted in reply to Georg Wrede | Georg Wrede wrote: > I admit this is a "feelings based" thing with most people I've talked with. It seems that on embedded platforms, many expect to write all the needed code themselves. It's also felt (possibly unduely??) that Phobos (or whatever general Win+*nix standard library) is mostly useless in embedded applications. I'd like to get to the bottom of this feeling. For example, Kris was unhappy that typeinfo imported std.strings. I can't figure out what the problem with that is. > To give a parallell (to explain my view here): There are many Linux distributions that are compiled with 386 as target. At the same time, their specs for memory, clock speed, etc. _in_practice_ rule out any machine not using recent Intel processors. I see this as a joke. > > Call this inconsistent specs. I'm discussing here so D would avoid this kind of inconsistencies. For the embedded people I've talked with, D without floating point would have been a good match. > Insisting on not needing hardware FP is ok. But to legitimize that, one has to cater to scarce resources in other areas too. Conversely, not genuinely making the language usable in smaller environments, makes striving to independence of FPU not worth the effort and inconvenience. It isn't necessary to strive to not use the FPU. Just don't use it unless floating point is actually needed. There is no need nor benefit to use floating point for calendar time. I've also seen people use floating point for random number generators - this is also neither necessary nor beneficial. |
April 06, 2006 Re: On processors for D | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | Walter Bright wrote:
> There is no need nor benefit to use floating point for calendar time.
> I've also seen people use floating point for random number generators
> - this is also neither necessary nor beneficial.
Heh, that's why I changed the subject. :-)
I'm not against the calendar thing. I'm only talking processors and system requirements, etc. here. And consistency of specs.
I'll think some more before actually commenting on the rest of your post.
|
April 06, 2006 Re: On processors for D ~ decoupling | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | Walter Bright wrote:
> Georg Wrede wrote:
>
>> I admit this is a "feelings based" thing with most people I've talked with. It seems that on embedded platforms, many expect to write all the needed code themselves. It's also felt (possibly unduely??) that Phobos (or whatever general Win+*nix standard library) is mostly useless in embedded applications.
>
>
> I'd like to get to the bottom of this feeling. For example, Kris was unhappy that typeinfo imported std.strings. I can't figure out what the problem with that is.
I'll try to explain it from my perspective:
1) You show an adversion to tightly coupled library modules ~ made a number of negative comments about the Java libraries in that respect ~ and have spelled out in the past a desire to duplicate code as necessary to avoid said tight coupling. This is good design, and it's one of the harder things to balance when building a library. Yet, there's flagrant cases where D tosses this out of the window along with the bathwater. Instead of adding a duplicate itoa() method (about 60 bytes of code), or perhaps linking to the C library version, TypeInfo gratuitously imports std.string and all its vast array of baggage. Heck, everyone makes mistakes, but your comment above indicates you feel this kind of tight coupling is perfectly fine?
Then, there's printf() being linked via Object ~ it's been 2 years since the push to have that removed (which you agreed to), yet it's now clear there's no intent to do so. So what's wrong with printf()? Well, it brings along with it almost the entire C IO library, including most of the wide-char processing and, of course, all the floating-point support, setup, and management. All completely unecessary where one doesn't use it. And it's linked at the base of the Object tree.
Without wishing to put too fine a point on it, you continue to do just exactly what you preach against; and there's apparently no good reason for it.
2) Not everyone likes Phobos. One might think you'd be happy to encourage (support, even!) alternate libraries that might far exceed the utility and/or design parameters of Phobos itself. Yet, by tightly coupling the D language to Phobos, you make life difficult for those alternate libraries. And for what reason? It makes no sense at all.
If you'd decouple the language from the library, you'd end up with something very close to Ares. It's lean, efficient, and very flexible. In fact, it lends itself very well to others building a working D compiler & environment ~ the kind of thing that helps increase adoption by decreasing concerns. By encouraging development of alternate libraries, the D language stands a better chance of having a good one. Via judicious decoupling, you can keep the resultant executable lean and mean ~ making it more attractive to the embedded market, amongst others. D might even avoid having to link the FPU management code by default :-P
You said "Kris was unhappy that typeinfo imported std.strings. I can't figure out what the problem with that is" ~~ I hope this helps you get there.
|
April 06, 2006 Re: On processors for D ~ decoupling | ||||
---|---|---|---|---|
| ||||
Posted in reply to kris | kris wrote: > Walter Bright wrote: >> I'd like to get to the bottom of this feeling. For example, Kris was unhappy that typeinfo imported std.strings. I can't figure out what the problem with that is. > > > I'll try to explain it from my perspective: > > 1) You show an adversion to tightly coupled library modules ~ made a number of negative comments about the Java libraries in that respect ~ and have spelled out in the past a desire to duplicate code as necessary to avoid said tight coupling. This is good design, and it's one of the harder things to balance when building a library. Yet, there's flagrant cases where D tosses this out of the window along with the bathwater. The trouble with Java was that even the most trivial program pulled in *everything*, including the graphics library. The typeinfo for a particular type is only linked in if that type is actually used in a user program. > Instead of adding a duplicate itoa() method (about 60 bytes of code), or perhaps linking to the C library version, TypeInfo gratuitously imports std.string and all its vast array of baggage. Heck, everyone makes mistakes, but your comment above indicates you feel this kind of tight coupling is perfectly fine? Although there is a lot of code in std.string, unreferenced free functions in it should be discarded by the linker. A check of the generated .map file should verify this - it is certainly supposed to work that way. One problem Java has is that there are no free functions, so referencing one function wound up pulling in every part of the class the function resided in. > Then, there's printf() being linked via Object ~ it's been 2 years since the push to have that removed (which you agreed to), yet it's now clear there's no intent to do so. So what's wrong with printf()? Well, it brings along with it almost the entire C IO library, including most of the wide-char processing and, of course, all the floating-point support, setup, and management. All completely unecessary where one doesn't use it. And it's linked at the base of the Object tree. printf doesn't pull in the floating point library (I went to a lot of effort to make that so!). It does pull in the C IO library, which is very hard to not pull in (there always seems to be something referencing it). It shouldn't pull in the C wide character stuff. D's IO (writefln) will pull in C's IO anyway, so the only thing extra is the integer version of the specific printf code (about 4K). > 2) Not everyone likes Phobos. One might think you'd be happy to encourage (support, even!) alternate libraries that might far exceed the utility and/or design parameters of Phobos itself. Yet, by tightly coupling the D language to Phobos, you make life difficult for those alternate libraries. And for what reason? It makes no sense at all. The only parts of phobos directly referenced by the compiler are typeinfo, object, and the code in internal. > If you'd decouple the language from the library, you'd end up with something very close to Ares. It's lean, efficient, and very flexible. In fact, it lends itself very well to others building a working D compiler & environment ~ the kind of thing that helps increase adoption by decreasing concerns. By encouraging development of alternate libraries, the D language stands a better chance of having a good one. Via judicious decoupling, you can keep the resultant executable lean and mean ~ making it more attractive to the embedded market, amongst others. D might even avoid having to link the FPU management code by default :-P > > > You said "Kris was unhappy that typeinfo imported std.strings. I can't figure out what the problem with that is" ~~ I hope this helps you get there. And I hope I responded adequately. |
April 06, 2006 Re: On processors for D ~ decoupling | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | As I said, that viewpoint is from my perspective ~ the intent was certainly not to elicit a defensive response. Instead, I'd hoped you'd be open to some suggestions; More inline: Walter Bright wrote: > kris wrote: > >> Walter Bright wrote: >> >>> I'd like to get to the bottom of this feeling. For example, Kris was unhappy that typeinfo imported std.strings. I can't figure out what the problem with that is. >> >> >> >> I'll try to explain it from my perspective: >> >> 1) You show an adversion to tightly coupled library modules ~ made a number of negative comments about the Java libraries in that respect ~ and have spelled out in the past a desire to duplicate code as necessary to avoid said tight coupling. This is good design, and it's one of the harder things to balance when building a library. Yet, there's flagrant cases where D tosses this out of the window along with the bathwater. > > > The trouble with Java was that even the most trivial program pulled in *everything*, including the graphics library. The typeinfo for a particular type is only linked in if that type is actually used in a user program. Yes, that's correct. But typeinfo is a rather rudimetary part of the language support. Wouldn't you agree? If I, for example, declare an array of 10 bytes (static byte[10]) then I'm bound over to import std.string ~ simply because TypeInfo_StaticArray wants to use std.string.toString(int), rather than the C library version of itoa() or a "low-level support" version instead. That's tight-coupling within very low-level language support. Uncool. Wouldn't you at least agree that specific instance is hardly an absolute necessity? >> Instead of adding a duplicate itoa() method (about 60 bytes of code), or perhaps linking to the C library version, TypeInfo gratuitously imports std.string and all its vast array of baggage. Heck, everyone makes mistakes, but your comment above indicates you feel this kind of tight coupling is perfectly fine? > > > Although there is a lot of code in std.string, unreferenced free functions in it should be discarded by the linker. A check of the generated .map file should verify this - it is certainly supposed to work that way. One problem Java has is that there are no free functions, so referencing one function wound up pulling in every part of the class the function resided in. This is exactly the case with printf <g>. It winds up linking the world because it's a general purpose utility function that does all kinds of conversion and all kinds of IO. Printf() is an all or nothing design ~ you can't selectively link pieces of it. That's usually not a problem. However, you've chosen to bind it to low-level language support (in the root Object). That choice causes tight coupling between the language low-level support and a high-level library function ~ one which ought to be optional. Wouldn't you at least agree this specific case is not necessary for the D language to function correctly? That there are other perfectly workable alternatives? >> Then, there's printf() being linked via Object ~ it's been 2 years since the push to have that removed (which you agreed to), yet it's now clear there's no intent to do so. So what's wrong with printf()? Well, it brings along with it almost the entire C IO library, including most of the wide-char processing and, of course, all the floating-point support, setup, and management. All completely unecessary where one doesn't use it. And it's linked at the base of the Object tree. > > > printf doesn't pull in the floating point library (I went to a lot of effort to make that so!). It does pull in the C IO library, which is very hard to not pull in (there always seems to be something referencing it). It shouldn't pull in the C wide character stuff. D's IO (writefln) will pull in C's IO anyway, so the only thing extra is the integer version of the specific printf code (about 4K). How can it convert %f, %g and so on if it doesn't use FP support at all? Either way, it's not currently possible to build a D program without a swathe of FP support code, printf, the entire C IO package, wide-char support, and a whole lot more besides. I'd assumed the linked FP support was for printf, but perhaps it's for std.string instead? I've posted the linker maps (in the past) to illustrate exactly this. There's no absolute need for most of this stuff. It shouldn't be bound at the low level. >> 2) Not everyone likes Phobos. One might think you'd be happy to encourage (support, even!) alternate libraries that might far exceed the utility and/or design parameters of Phobos itself. Yet, by tightly coupling the D language to Phobos, you make life difficult for those alternate libraries. And for what reason? It makes no sense at all. > > > The only parts of phobos directly referenced by the compiler are typeinfo, object, and the code in internal. No argument there. Yet those modules are slowly importing chunks of Phobos, making them dependencies also. My point is, and has always been, there's no need for those secondary dependencies. Especially at the level of language-support (like typeinfo and object). > > >> If you'd decouple the language from the library, you'd end up with something very close to Ares. It's lean, efficient, and very flexible. In fact, it lends itself very well to others building a working D compiler & environment ~ the kind of thing that helps increase adoption by decreasing concerns. By encouraging development of alternate libraries, the D language stands a better chance of having a good one. Via judicious decoupling, you can keep the resultant executable lean and mean ~ making it more attractive to the embedded market, amongst others. D might even avoid having to link the FPU management code by default :-P >> >> >> You said "Kris was unhappy that typeinfo imported std.strings. I can't figure out what the problem with that is" ~~ I hope this helps you get there. > > > And I hope I responded adequately. Are you not at all interested in improving this aspect of the language usage? |
April 06, 2006 Re: On processors for D ~ decoupling | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | On Fri, 07 Apr 2006 06:52:08 +1000, Walter Bright <newshound@digitalmars.com> wrote: > And I hope I responded adequately. I don't think you did. Once again you skirted the issues with politian-like answers. -- Derek Parnell Melbourne, Australia |
April 06, 2006 Re: On processors for D ~ decoupling | ||||
---|---|---|---|---|
| ||||
Posted in reply to kris | kris wrote: > Yes, that's correct. But typeinfo is a rather rudimetary part of the language support. Wouldn't you agree? If I, for example, declare an array of 10 bytes (static byte[10]) then I'm bound over to import std.string ~ simply because TypeInfo_StaticArray wants to use std.string.toString(int), rather than the C library version of itoa() or a "low-level support" version instead. It has nothing to do with having a static byte[10] declaration. For the program: void main() { static byte[10] b; } The only things referenced by the object file are _main, __acrtused_con, and __Dmain. You can verify this by running obj2asm on the output, which gives: ------------------------------------- _TEXT segment dword use32 public 'CODE' ;size is 0 _TEXT ends _DATA segment para use32 public 'DATA' ;size is 0 _DATA ends CONST segment para use32 public 'CONST' ;size is 0 CONST ends _BSS segment para use32 public 'BSS' ;size is 10 _BSS ends FLAT group includelib phobos.lib extrn _main extrn __acrtused_con extrn __Dmain __Dmain COMDAT flags=x0 attr=x0 align=x0 _TEXT segment assume CS:_TEXT _TEXT ends _DATA segment _DATA ends CONST segment CONST ends _BSS segment _BSS ends __Dmain comdat assume CS:__Dmain xor EAX,EAX ret __Dmain ends end ---------------------------------- Examining the .map file produced shows that only these functions are pulled in from std.string: 0002:00002364 _D3std6string7iswhiteFwZi 00404364 0002:000023A4 _D3std6string3cmpFAaAaZi 004043A4 0002:000023E8 _D3std6string4findFAawZi 004043E8 0002:00002450 _D3std6string8toStringFkZAa 00404450 0002:000024CC _D3std6string9inPatternFwAaZi 004044CC 0002:00002520 _D3std6string6columnFAaiZk 00404520 I do not know offhand why a couple of those are pulled in, but I suggest that obj2asm and the generated .map files are invaluable at determining what pulls in what. Sometimes the results are surprising. > That's tight-coupling within very low-level language support. Uncool. > Wouldn't you at least agree that specific instance is hardly an absolute necessity? std.string.toString is 124 bytes long, and doesn't pull anything else in (except see below). Writing another version of it in typeinfo isn't going to reduce the size of the program *at all*, in fact, it will likely increase it because now there'll be two versions of it. >> Although there is a lot of code in std.string, unreferenced free functions in it should be discarded by the linker. A check of the generated .map file should verify this - it is certainly supposed to work that way. One problem Java has is that there are no free functions, so referencing one function wound up pulling in every part of the class the function resided in. > This is exactly the case with printf <g>. It winds up linking the world No, it does not link in the world, floating point, or graphics libraries. It links in C's standard I/O (which usually gets linked in anyway), and about 4000 bytes of code. That's somewhat less than a megabyte <g>. > because it's a general purpose utility function that does all kinds of conversion and all kinds of IO. Printf() is an all or nothing design ~ you can't selectively link pieces of it. > > That's usually not a problem. However, you've chosen to bind it to low-level language support (in the root Object). That choice causes tight coupling between the language low-level support and a high-level library function ~ one which ought to be optional. > > Wouldn't you at least agree this specific case is not necessary for the D language to function correctly? That there are other perfectly workable alternatives? It's just not a big deal. Try the following: extern (C) int printf(char* f, ...) { return 0; } void main() { static byte[10] b; } and compare the difference in exe file sizes, with and without the printf stub. >> printf doesn't pull in the floating point library (I went to a lot of effort to make that so!). It does pull in the C IO library, which is very hard to not pull in (there always seems to be something referencing it). It shouldn't pull in the C wide character stuff. D's IO (writefln) will pull in C's IO anyway, so the only thing extra is the integer version of the specific printf code (about 4K). > How can it convert %f, %g and so on if it doesn't use FP support at all? It's magic! Naw, it's just that if you actually use floating point in a program, the compiler emits a special extern reference (to __fltused) which pulls in the floating point IO formatting code. Otherwise, it defaults to just a stub. Try it. > Either way, it's not currently possible to build a D program without a swathe of FP support code, > printf, > the entire C IO package, > wide-char support, > and a whole lot more besides. I'd assumed the linked FP support was for printf, but perhaps it's for std.string instead? I've posted the linker maps (in the past) to illustrate exactly this. My point is that assuming what is pulled in by what is about as reliable as guessing where the bottlenecks in one's code is. You can't tell bottlenecks without a profiler, and you've got both hands tied behind your back trying to figure out who pulls in what if you're not using .map files, grep, and obj2asm. > Are you not at all interested in improving this aspect of the language usage? Sure, but based on accurate information. Pulling printf won't do anything. Try it if you don't agree. For example, which modules pull in the floating point formatting code? It isn't printf. We can find out by doing a grep for __fltused: boxer.obj: __fltused complex.obj: __fltused conv.obj: __fltused date.obj: __fltused demangle.obj: __fltused format.obj: __fltused gamma.obj: __fltused math.obj: __fltused math2.obj: __fltused outbuffer.obj: __fltused stream.obj: __fltused string.obj: __fltused ti_Acdouble.obj: __fltused ti_Acfloat.obj: __fltused ti_Acreal.obj: __fltused ti_Adouble.obj: __fltused ti_Afloat.obj: __fltused ti_Areal.obj: __fltused ti_cdouble.obj: __fltused ti_cfloat.obj: __fltused ti_creal.obj: __fltused ti_double.obj: __fltused ti_float.obj: __fltused ti_real.obj: __fltused Some examination of the .map file shows that the only one of these pulled in by default is std.string. So I think a reasonable approach would be to look at removing the floating point from std.string - printf isn't the problem, nor is referencing a function in std.string. |
April 06, 2006 Re: On processors for D ~ decoupling | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | On Thu, 06 Apr 2006 13:52:08 -0700, Walter Bright wrote: >> Instead of adding a duplicate itoa() method (about 60 bytes of code), or perhaps linking to the C library version, TypeInfo gratuitously imports std.string and all its vast array of baggage. Heck, everyone makes mistakes, but your comment above indicates you feel this kind of tight coupling is perfectly fine? > > Although there is a lot of code in std.string, unreferenced free functions in it should be discarded by the linker. A check of the generated .map file should verify this - it is certainly supposed to work that way. One problem Java has is that there are no free functions, so referencing one function wound up pulling in every part of the class the function resided in. The following program ... void main() {} linked in the following modules (from the .map file) ---------------- ??0RTLHeap@@QAE@XZ ??0RTLHeapBlock@@QAE@IAAV0@@Z ??0RTLHeapBlock@@QAE@XZ ??0RTLHeapBlockHeader@@QAE@I@Z ??0RTLMultiPool@@QAE@II@Z ??0RTLPool@@QAE@II@Z ??0Type_info@@AAA@ABV0@@Z ??0bad_cast@std@@QAE@ABV01@@Z ??0bad_cast@std@@QAE@XZ ??0exception@std@@QAE@XZ ??0type_info@std@@IAE@XZ ??1RTLMultiPool@@QAE@XZ ??1Type_info@@UAA@XZ ??1__eh_cv@@QAE@XZ ??1bad_cast@std@@UAE@XZ ??1bad_exception@std@@UAE@XZ ??1bad_typeid@std@@UAE@XZ ??1exception@std@@UAE@XZ ??1type_info@std@@UAA@XZ ??2@YAPAXI@Z ??3@YAXPAX@Z ??_GType_info@@UAEPAXI@Z ??_Gbad_cast@std@@UAEPAXI@Z ??_Gbad_exception@std@@UAEPAXI@Z ??_Gbad_typeid@std@@UAEPAXI@Z ??_Gexception@std@@UAEPAXI@Z ??_Gtype_info@std@@UAEPAXI@Z ??_QType_info@@6B@ ??_Qbad_cast@std@@6B@ ??_Qbad_exception@std@@6B@ ??_Qbad_typeid@std@@6B@ ??_Qexception@std@@6B@ ??_Qtype_info@std@@6B@ ?Alloc@RTLHeap@@QAEPAXK@Z ?Alloc@RTLMultiPool@@QAEPAXK@Z ?Alloc@RTLPool@@QAEPAXXZ ?Claim@RTLHeapBlock@@QAEHI@Z ?CreateMainHeap@RTLHeap@@SAXXZ ?CreateMainHeap@RTLMultiPool@@SAXXZ ?FixSize@RTLHeap@@AAEII@Z ?Free@RTLHeap@@QAEXPAX@Z ?Free@RTLMultiPool@@QAEXPAX@Z ?Free@RTLPool@@QAEXPAX@Z ?GetNext@RTLHeapBlock@@QAEAAV1@XZ ?Handle_VC_Exception@@YAPAUEhstack@@PAU_EXCEPTION_RECORD@@H@Z ?InsertAfter@RTLHeapBlock@@QAEXAAV1@@Z ?MergeBackward@RTLHeapBlock@@QAEHXZ ?MergeForward@RTLHeapBlock@@QAEHXZ ?MoreCore@RTLHeap@@AAEPAVRTLHeapBlock@@I@Z ?Realloc@RTLHeap@@QAEPAXPAXK@Z ?Realloc@RTLMultiPool@@QAEPAXPAXK@Z ?Reclaim@RTLHeapBlock@@QAEHIAAV1@@Z ?Remove@RTLHeapBlock@@QAEXXZ ?SelectFree@RTLMultiPool@@AAEXPAX@Z ?ThreadNewBlock@RTLPool@@AAEXXZ ?__cpp_local_unwind@@YAXPAU_CPP_Establisher_Frame@@PADH@Z ?__do_newalloc@@YAPAXI@Z ?__eh_delete@@YAXPAX@Z ?__eh_delp@@3P6AXPAX@ZA ?__eh_error@@YAXXZ ?__eh_new@@YAPAXI@Z ?__eh_newp@@3P6APAXI@ZA ?__eh_throw@@YAXPBDP6CHXZIZZ ?__internal_cpp_framehandler@@YA?AW4_EXCEPTION_DISPOSITION@@PAUfunc_data@@PAU_EXCEPTION_RECORD@@PAU_CPP_Establisher_Frame@@PAU_CONTEXT@@PAX@Z ?__new_handler_type@@3HA ?__rtti_cast@@YAPAXPAX0PBD1H@Z ?__rtti_match@@YAHPBD0PAI@Z ?_call_catch_block@@YAXJIP6CHXZ@Z ?_new_handler@@3P6AHI@ZA ?match_with_vc_throw_type@@YAHPAUThrowInfo@@PADPAI@Z ?pMainHeap@RTLHeap@@0PAV1@A ?pMainHeap@RTLMultiPool@@0PAV1@A ?pPools@RTLPool@@0PAV1@A ?set_terminate@@YAP6AXXZP6AXXZ@Z ?set_terminate@std@@YAP6AXXZP6AXXZ@Z ?set_unexpected@@YAP6AXXZP6AXXZ@Z ?set_unexpected@std@@YAP6AXXZP6AXXZ@Z ?terminate@@YAXXZ ?terminate_fp@@3P6AXXZA ?unexpected@@YAXXZ ?unexpected_fp@@3P6AXXZA ?what@bad_cast@std@@UBEPBDXZ ?what@bad_exception@std@@UBEPBDXZ ?what@bad_typeid@std@@UBEPBDXZ ?what@exception@std@@UBEPBDXZ _CW_USEDEFAULT _CloseHandle@4 _CreateSemaphoreA@16 _CreateThread@24 _D3gcx10notbinsizeG12k _D3gcx14SENTINEL_EXTRAk _D3gcx2GC10genCollectFZv _D3gcx2GC10initializeFZv _D3gcx2GC10removeRootFPvZv _D3gcx2GC11__invariantFZv _D3gcx2GC11fullCollectFZv _D3gcx2GC11removeRangeFPvZv _D3gcx2GC12mallocNoSyncFkZPv _D3gcx2GC12setFinalizerFPvPFPvPvZvZv _D3gcx2GC14scanStaticDataFC3gcx2GCZv _D3gcx2GC14setStackBottomFPvZv _D3gcx2GC18fullCollectNoStackFZv _D3gcx2GC4DtorFZv _D3gcx2GC4filePa _D3gcx2GC4freeFPvZv _D3gcx2GC4linek _D3gcx2GC5checkFPvZv _D3gcx2GC6callocFkkZPv _D3gcx2GC6enableFZv _D3gcx2GC6gcLockC9ClassInfo _D3gcx2GC6mallocFkZPv _D3gcx2GC7addRootFPvZv _D3gcx2GC7disableFZv _D3gcx2GC7reallocFPvkZPv _D3gcx2GC8addRangeFPvPvZv _D3gcx2GC8capacityFPvZk _D3gcx2GC8getStatsFJS7gcstats7GCStatsZv _D3gcx2GC8minimizeFZv _D3gcx3Gcx10removeRootFPvZv _D3gcx3Gcx11fullcollectFPvZk _D3gcx3Gcx11removeRangeFPvZv _D3gcx3Gcx16fullcollectshellFZk _D3gcx3Gcx4DtorFZv _D3gcx3Gcx4markFPvPvZv _D3gcx3Gcx7addRootFPvZv _D3gcx3Gcx7findBinFkZh _D3gcx3Gcx7newPoolFkZPS3gcx4Pool _D3gcx3Gcx8addRangeFPvPvZv _D3gcx3Gcx8bigAllocFkZPv _D3gcx3Gcx8findPoolFPvZPS3gcx4Pool _D3gcx3Gcx8findSizeFPvZk _D3gcx3Gcx9allocPageFhZi _D3gcx4Pool10allocPagesFkZk _D3gcx4Pool10initializeFkZv _D3gcx4Pool4DtorFZv _D3gcx7binsizeG12k _D3gcx9GCVERSIONk _D3std10moduleinit12_moduleCtor2FAC10ModuleInfoiZv _D3std10moduleinit15ModuleCtorError5_ctorFC10ModuleInfoZC3std10moduleinit15ModuleCtorError _D3std10moduleinit17_moduleinfo_dtorsAC10ModuleInfo _D3std10moduleinit19_moduleinfo_dtors_ik _D3std11outofmemory20OutOfMemoryException1sAa _D3std11outofmemory20OutOfMemoryException8toStringFZAa _D3std1c6stdarg15__T8va_startTkZ8va_startFJPvKkZv _D3std1c6stdarg6va_endFPvZv _D3std2gc11newCapacityFkkZk _D3std2gc11newCapacityFkkZk9log2plus1FkZi _D3std2gc13new_finalizerFPvPvZv _D3std2gc3_gcC3gcx2GC _D3std3uni10isUniAlphaFwZi _D3std3uni10isUniLowerFwZi _D3std3uni10isUniUpperFwZi _D3std3uni10toUniLowerFwZw _D3std3uni10toUniUpperFwZw _D3std3utf10UTF8strideG256h _D3std3utf12UtfException5_ctorFAakZC3std3utf12UtfException _D3std3utf12isValidDcharFwZx _D3std3utf6decodeFAaKkZw _D3std3utf6encodeFKAawZv _D3std3utf6strideFAakZk _D3std3utf6toUTF8FG4awZAa _D3std5array16ArrayBoundsError5_ctorFAakZC3std5array16ArrayBoundsError _D3std6string10whitespaceG6a _D3std6string2LSw _D3std6string2PSw _D3std6string3cmpFAaAaZi _D3std6string4findFAawZi _D3std6string6columnFAaiZi _D3std6string6digitsG10a _D3std6string7iswhiteFwZi _D3std6string7lettersG52a _D3std6string7newlineG2a _D3std6string8toStringFkZAa _D3std6string9hexdigitsG16a _D3std6string9inPatternFwAaZi _D3std6string9lowercaseG26a _D3std6string9octdigitsG8a _D3std6string9uppercaseG26a _D3std6thread11ThreadError5_ctorFAaZC3std6thread11ThreadError _D3std6thread20os_query_stackBottomFZPv _D3std6thread6Thread10allThreadsG1024C3std6thread6Thread _D3std6thread6Thread10threadLockC6Object _D3std6thread6Thread11_staticDtorFZv _D3std6thread6Thread11setPriorityFE3std6thread6Thread8PRIORITYZv _D3std6thread6Thread11thread_initFZv _D3std6thread6Thread13allThreadsDimk _D3std6thread6Thread22getCurrentThreadHandleFZT3std1c7windows7windows6HANDLE _D3std6thread6Thread3runFZi _D3std6thread6Thread4waitFZv _D3std6thread6Thread4waitFkZv _D3std6thread6Thread5_ctorFZC3std6thread6Thread _D3std6thread6Thread5errorFAaZv _D3std6thread6Thread5pauseFZv _D3std6thread6Thread5startFZv _D3std6thread6Thread6getAllFZAC3std6thread6Thread _D3std6thread6Thread6resumeFZv _D3std6thread6Thread7getThisFZC3std6thread6Thread _D3std6thread6Thread8getStateFZE3std6thread6Thread2TS _D3std6thread6Thread8nthreadsk _D3std6thread6Thread8pauseAllFZv _D3std6thread6Thread9resumeAllFZv _D3std8typeinfo2Aa11TypeInfo_Aa5tsizeFZk _D3std8typeinfo2Aa11TypeInfo_Aa6equalsFPvPvZi _D3std8typeinfo2Aa11TypeInfo_Aa7compareFPvPvZi _D3std8typeinfo2Aa11TypeInfo_Aa7getHashFPvZk _D3std8typeinfo2Aa11TypeInfo_Aa8toStringFZAa _D3std8typeinfo7ti_char10TypeInfo_a4swapFPvPvZv _D3std8typeinfo7ti_char10TypeInfo_a5tsizeFZk _D3std8typeinfo7ti_char10TypeInfo_a6equalsFPvPvZi _D3std8typeinfo7ti_char10TypeInfo_a7compareFPvPvZi _D3std8typeinfo7ti_char10TypeInfo_a7getHashFPvZk _D3std8typeinfo7ti_char10TypeInfo_a8toStringFZAa _D3std8typeinfo7ti_uint10TypeInfo_k4swapFPvPvZv _D3std8typeinfo7ti_uint10TypeInfo_k5tsizeFZk _D3std8typeinfo7ti_uint10TypeInfo_k6equalsFPvPvZi _D3std8typeinfo7ti_uint10TypeInfo_k7compareFPvPvZi _D3std8typeinfo7ti_uint10TypeInfo_k7getHashFPvZk _D3std8typeinfo7ti_uint10TypeInfo_k8toStringFZAa _D5win3210os_mem_mapFkZPv _D5win3212os_mem_unmapFPvkZi _D5win3213os_mem_commitFPvkkZi _D5win3215os_mem_decommitFPvkkZi _D5win3220os_query_stackBottomFZPv _D5win3222os_query_staticdatasegFPPvPkZv _D6gcbits6GCBits10BITS_SHIFTi _D6gcbits6GCBits13BITS_PER_WORDi _D6gcbits6GCBits3setFkZv _D6gcbits6GCBits4DtorFZv _D6gcbits6GCBits4baseFZPk _D6gcbits6GCBits4copyFPS6gcbits6GCBitsZv _D6gcbits6GCBits4testFkZk _D6gcbits6GCBits4zeroFZv _D6gcbits6GCBits5allocFkZv _D6gcbits6GCBits9BITS_MASKi _D6gcbits6GCBits9testClearFkZk _D6object14TypeInfo_Array4swapFPvPvZv _D6object14TypeInfo_Array5tsizeFZk _D6object14TypeInfo_Array6equalsFPvPvZi _D6object14TypeInfo_Array7compareFPvPvZi _D6object14TypeInfo_Array7getHashFPvZk _D6object14TypeInfo_Array8toStringFZAa _D6object14TypeInfo_Class5tsizeFZk _D6object14TypeInfo_Class6equalsFPvPvZi _D6object14TypeInfo_Class7compareFPvPvZi _D6object14TypeInfo_Class7getHashFPvZk _D6object14TypeInfo_Class8toStringFZAa _D6object15TypeInfo_Struct5tsizeFZk _D6object15TypeInfo_Struct6equalsFPvPvZi _D6object15TypeInfo_Struct7compareFPvPvZi _D6object15TypeInfo_Struct7getHashFPvZk _D6object15TypeInfo_Struct8toStringFZAa _D6object16TypeInfo_Pointer4swapFPvPvZv _D6object16TypeInfo_Pointer5tsizeFZk _D6object16TypeInfo_Pointer6equalsFPvPvZi _D6object16TypeInfo_Pointer7compareFPvPvZi _D6object16TypeInfo_Pointer7getHashFPvZk _D6object16TypeInfo_Pointer8toStringFZAa _D6object16TypeInfo_Typedef4swapFPvPvZv _D6object16TypeInfo_Typedef5tsizeFZk _D6object16TypeInfo_Typedef6equalsFPvPvZi _D6object16TypeInfo_Typedef7compareFPvPvZi _D6object16TypeInfo_Typedef7getHashFPvZk _D6object16TypeInfo_Typedef8toStringFZAa _D6object17TypeInfo_Delegate5tsizeFZk _D6object17TypeInfo_Delegate8toStringFZAa _D6object17TypeInfo_Function5tsizeFZk _D6object17TypeInfo_Function8toStringFZAa _D6object20TypeInfo_StaticArray4swapFPvPvZv _D6object20TypeInfo_StaticArray5tsizeFZk _D6object20TypeInfo_StaticArray6equalsFPvPvZi _D6object20TypeInfo_StaticArray7compareFPvPvZi _D6object20TypeInfo_StaticArray7getHashFPvZk _D6object20TypeInfo_StaticArray8toStringFZAa _D6object25TypeInfo_AssociativeArray5tsizeFZk _D6object25TypeInfo_AssociativeArray8toStringFZAa _D6object5Error5_ctorFAaZC6object5Error _D6object6Object5opCmpFC6ObjectZi _D6object6Object5printFZv _D6object6Object6toHashFZk _D6object6Object8opEqualsFC6ObjectZi _D6object6Object8toStringFZAa _D6object8TypeInfo4swapFPvPvZv _D6object8TypeInfo5opCmpFC6ObjectZi _D6object8TypeInfo5tsizeFZk _D6object8TypeInfo6equalsFPvPvZi _D6object8TypeInfo6toHashFZk _D6object8TypeInfo7compareFPvPvZi _D6object8TypeInfo7getHashFPvZk _D6object8TypeInfo8opEqualsFC6ObjectZi _D6object9Exception5_ctorFAaZC9Exception _D6object9Exception5printFZv _D6object9Exception8toStringFZAa _DeleteCriticalSection@4 _DeleteFileA@4 _DuplicateHandle@28 _EnterCriticalSection@4 _ExitProcess@4 _ExitThread@4 _FREEBUF _FileTimeToDosDateTime@12 _FindClose@4 _FindFirstFileA@8 _FindNextFileA@8 _FreeEnvironmentStringsA@4 _GetACP@0 _GetCPInfo@8 _GetCommandLineA@0 _GetCurrentProcess@0 _GetCurrentThread@0 _GetCurrentThreadId@0 _GetEnvironmentStrings@0 _GetFileType@4 _GetLastError@0 _GetModuleFileNameA@12 _GetModuleHandleA@4 _GetOEMCP@0 _GetStdHandle@4 _GetStringTypeA@20 _GetThreadContext@8 _GetTickCount@0 _GetVersion@0 _GlobalAlloc@8 _GlobalFree@4 _HKEY_CLASSES_ROOT _HKEY_CURRENT_CONFIG _HKEY_CURRENT_USER _HKEY_DYN_DATA _HKEY_LOCAL_MACHINE _HKEY_PERFORMANCE_DATA _HKEY_USERS _HWND_DESKTOP _IDC_ARROW _IDC_CROSS _IDI_APPLICATION _INVALID_FILE_SIZE _INVALID_HANDLE_VALUE _INVALID_SET_FILE_POINTER _InitializeCriticalSection@4 _LCMapStringA@24 _LeaveCriticalSection@4 _MAILSLOT_NO_MESSAGE _MAILSLOT_WAIT_FOREVER _MessageBoxA@16 _MultiByteToWideChar@24 _REG_CREATED_NEW_KEY _REG_OPENED_EXISTING_KEY _RTLPoolCreate _RaiseException@16 _ReadFile@20 _ReleaseSemaphore@12 _ResumeThread@4 _RtlUnwind@16 _SetConsoleCtrlHandler@8 _SetFilePointer@16 _SetHandleCount@4 _SetThreadPriority@8 _SetUnhandledExceptionFilter@4 _SuspendThread@4 _ThreadStarted _UnhandledExceptionFilter@4 _VirtualAlloc@16 _VirtualFree@12 _WaitForSingleObject@8 _WideCharToMultiByte@32 _WriteConsoleA@20 _WriteFile@20 __8087 __8087_init __80x87 __87TOPSW@ __Class_10ModuleInfo __Class_10TypeInfo_a __Class_10TypeInfo_k __Class_11TypeInfo_Aa __Class_13TypeInfo_Enum __Class_14TypeInfo_Array __Class_14TypeInfo_Class __Class_15TypeInfo_Struct __Class_16TypeInfo_Pointer __Class_16TypeInfo_Typedef __Class_17TypeInfo_Delegate __Class_17TypeInfo_Function __Class_20TypeInfo_StaticArray __Class_25TypeInfo_AssociativeArray __Class_3gcx2GC __Class_3gcx6GCLock __Class_3std10moduleinit15ModuleCtorError __Class_3std11outofmemory20OutOfMemoryException __Class_3std3utf12UtfException __Class_3std3utf8UtfError __Class_3std5array16ArrayBoundsError __Class_3std6string15StringException __Class_3std6thread11ThreadError __Class_3std6thread6Thread __Class_6Object __Class_6object5Error __Class_8TypeInfo __Class_9ClassInfo __Class_9Exception __D3std6thread6Thread11threadstartWPvZk@4 __DBLINT87@ __DBLLNG87@ __DBLTO87@ __DOSIGN __DTST87@ __DestroySemaphore __Dmain __Exit __FCOMPP@ __FEEXCEPT __FE_DFL_ENV __FLOATCVT __FLTTO87@ __FTEST0@ __FTEST@ __InitSemaphoreSys __LCMP@ __LDIV@ __LMUL@ __ModuleInfo_3adi __ModuleInfo_3gcx __ModuleInfo_3std10moduleinit __ModuleInfo_3std2gc __ModuleInfo_3std3utf __ModuleInfo_3std5ctype __ModuleInfo_3std5stdio __ModuleInfo_3std6format __ModuleInfo_3std6string __ModuleInfo_3std6thread __ModuleInfo_3std8typeinfo2Aa __ModuleInfo_6aApply __ModuleInfo_6dmain2 __ModuleInfo_6gcbits __ModuleInfo_6object __ModuleInfo_8arraycat __ReleaseSemaphore __SCANFLOAT __SET_ERRNO __SET_NT_ERRNO __STD_critical __STD_init_std_files __STD_monitor_staticdtor __STD_signal __STI_critical __STI_fltused __STI_init_std_files __STI_io_ctor __STI_monitor_staticctor __STI_signal __ULDIV@ __WDOSIGN __WSCANFLOAT __WaitSemaphore ___CPPExceptionFilter@4 ___SD?%___heap32_multpool_cpp1525433864_ ___SI?%___heap32_multpool_cpp1525433864_ ___alloca ___argc ___argv ___build_environ ___callve ___cpp_init ___cpp_init_ptr ___faterr ___fcloseall ___fhnd_info ___floatfmt ___fp_lock ___fp_sigfunc ___fp_unlock ___fpclassify_ld ___init_environ_ptr ___init_mbctype_ptr ___initmbctype ___itoa ___locale_chars ___locale_codepage ___locale_decimal_const ___locale_decpoint ___locale_ident ___locale_mbsize ___mb_cpinfo ___mb_cpinfoN ___mbcodepage ___mbcpinfo ___mblcid ___module_handle ___pfloatfmt ___pscanfloat ___rtl_clean_cppexceptions ___rtl_criticalsection ___rtl_init_cppexceptions ___rtti?AVType_info@@ ___rtti?AVbad_cast@std@@ ___rtti?AVbad_exception@std@@ ___rtti?AVbad_typeid@std@@ ___rtti?AVexception@std@@ ___rtti?AVtype_info@std@@ ___sigill_sigfunc ___sigsegv_sigfunc ___terminate_done ___thdtbl ___threadstartex@4 ___ti?AVType_info@@ ___ti?AVbad_cast@std@@ ___ti?AVbad_exception@std@@ ___ti?AVbad_typeid@std@@ ___ti?AVexception@std@@ ___ti?AVtype_info@std@@ ___tiX ___unmangle_vc_exception_type ___ve_debughook ___wargv ___wfloatfmt ___wildcard ___wpfloatfmt ___wpscanfloat ___write_fp ___xcfilter __aApplycd1 __aApplycd2 __acmdln __acrtused_con __adDup __adEq __addthreadtableentry __alloca_probe __allocinit __argc __argv __assert __atexit_max __atexit_tbl __atexitp __atopsp __beginthreadex __call_except_block __chkstack __chkstk __cinit __clear87 __clearbss __control87 __cpp_framehandler __cppeh_sv __cpumode __ctype __d_OutOfMemory __d_arrayappend __d_arrayappendc __d_arraycat __d_arraycatn __d_arraysetlength __d_callfinalizer __d_create_exception_object __d_delmemory __d_exception_filter __d_framehandler __d_isbaseof __d_local_unwind __d_local_unwind2 __d_monitor_epilog __d_monitor_handler __d_monitor_prolog __d_monitorenter __d_monitorexit __d_monitorrelease __d_new __d_newarrayi __d_newclass __d_throw@4 __d_translate_se_to_d_exception __dodtors __dos_sethandlecount __doserrno __edata __end __endthreadex __environ __envptr __errno_set __except_handler3 __except_list __fatexit __fcloseallp __fe_cur_env __fgetc_nlock __fillbuf __fltused __flushbu __flushterm __fpreset __fputc_nlock __getthreaddata __global_unwind __hdlSemHandles __hookexitp __iSemLockCtrs __iSemNestCount __iSemThreadIds __imp__CloseHandle@4 __imp__CreateSemaphoreA@16 __imp__CreateThread@24 __imp__DeleteCriticalSection@4 __imp__DeleteFileA@4 __imp__DuplicateHandle@28 __imp__EnterCriticalSection@4 __imp__ExitProcess@4 __imp__ExitThread@4 __imp__FileTimeToDosDateTime@12 __imp__FindClose@4 __imp__FindFirstFileA@8 __imp__FindNextFileA@8 __imp__GetACP@0 __imp__GetCPInfo@8 __imp__GetCommandLineA@0 __imp__GetCurrentProcess@0 __imp__GetCurrentThread@0 __imp__GetCurrentThreadId@0 __imp__GetFileType@4 __imp__GetLastError@0 __imp__GetModuleFileNameA@12 __imp__GetModuleHandleA@4 __imp__GetOEMCP@0 __imp__GetStdHandle@4 __imp__GetStringTypeA@20 __imp__GetThreadContext@8 __imp__GetTickCount@0 __imp__InitializeCriticalSection@4 __imp__LCMapStringA@24 __imp__LeaveCriticalSection@4 __imp__MessageBoxA@16 __imp__MultiByteToWideChar@24 __imp__RaiseException@16 __imp__ReleaseSemaphore@12 __imp__ResumeThread@4 __imp__SetConsoleCtrlHandler@8 __imp__SetFilePointer@16 __imp__SetHandleCount@4 __imp__SetThreadPriority@8 __imp__SetUnhandledExceptionFilter@4 __imp__SuspendThread@4 __imp__UnhandledExceptionFilter@4 __imp__VirtualAlloc@16 __imp__VirtualFree@12 __imp__WaitForSingleObject@8 __imp__WideCharToMultiByte@32 __imp__WriteConsoleA@20 __init_10ModuleInfo __init_10TypeInfo_a __init_10TypeInfo_k __init_11TypeInfo_Aa __init_13TypeInfo_Enum __init_14TypeInfo_Array __init_14TypeInfo_Class __init_15TypeInfo_Struct __init_16TypeInfo_Pointer __init_16TypeInfo_Typedef __init_17TypeInfo_Delegate __init_17TypeInfo_Function __init_20TypeInfo_StaticArray __init_25TypeInfo_AssociativeArray __init_3adi5Array __init_3gcx2GC __init_3gcx3Gcx __init_3gcx4List __init_3gcx4Pool __init_3gcx5Range __init_3gcx6GCLock __init_3std10moduleinit15ModuleCtorError __init_3std11outofmemory20OutOfMemoryException __init_3std1c7windows7windows10BITMAPINFO __init_3std1c7windows7windows10LOGPALETTE __init_3std1c7windows7windows10OVERLAPPED __init_3std1c7windows7windows10SYSTEMTIME __init_3std1c7windows7windows11DLGTEMPLATE __init_3std1c7windows7windows11PAINTSTRUCT __init_3std1c7windows7windows11TEXTMETRICA __init_3std1c7windows7windows11WNDCLASSEXA __init_3std1c7windows7windows12MEMORYSTATUS __init_3std1c7windows7windows12PALETTEENTRY __init_3std1c7windows7windows13OPENFILENAMEA __init_3std1c7windows7windows13OPENFILENAMEW __init_3std1c7windows7windows15WIN32_FIND_DATA __init_3std1c7windows7windows16BITMAPINFOHEADER __init_3std1c7windows7windows16WIN32_FIND_DATAW __init_3std1c7windows7windows18FLOATING_SAVE_AREA __init_3std1c7windows7windows19SECURITY_ATTRIBUTES __init_3std1c7windows7windows21PIXELFORMATDESCRIPTOR __init_3std1c7windows7windows21TIME_ZONE_INFORMATION __init_3std1c7windows7windows24MEMORY_BASIC_INFORMATION __init_3std1c7windows7windows3MSG __init_3std1c7windows7windows4RECT __init_3std1c7windows7windows5POINT __init_3std1c7windows7windows6BITMAP __init_3std1c7windows7windows6LOGPEN __init_3std1c7windows7windows7CONTEXT __init_3std1c7windows7windows7RGBQUAD __init_3std1c7windows7windows8FILETIME __init_3std1c7windows7windows8LOGFONTA __init_3std1c7windows7windows9WNDCLASSA __init_3std2gc5Array __init_3std3utf12UtfException __init_3std3utf8UtfError __init_3std5array16ArrayBoundsError __init_3std6string15StringException __init_3std6thread11ThreadError __init_3std6thread6Thread __init_6Object __init_6gcbits6GCBits __init_6object5Error __init_6object9Interface __init_8TypeInfo __init_9ClassInfo __init_9Exception __iob __isctype __ismbblead __ismbcdigit __local_except_handler __local_unwind __mbctype __mbschr __minit __moddtor_3std6thread __moduleCtor __moduleDtor __moduleUnitTests __moduleinfo_array __nullext __opti_stosd __osfhnd __osmode __osver __pCPPExceptionFilter __pPreviousUnhandledExceptionFilter __pctype __pformat __pgmptr __pwctype __rtl_critical_enter __rtl_critical_exit __semerr __setargv __setenvp __setmbcp __status87 __szSemPrefix __szSemPrefixLen __tab_size __thread1 __thread_init __vtbl_10ModuleInfo __vtbl_10TypeInfo_a __vtbl_10TypeInfo_k __vtbl_11TypeInfo_Aa __vtbl_13TypeInfo_Enum __vtbl_14TypeInfo_Array __vtbl_14TypeInfo_Class __vtbl_15TypeInfo_Struct __vtbl_16TypeInfo_Pointer __vtbl_16TypeInfo_Typedef __vtbl_17TypeInfo_Delegate __vtbl_17TypeInfo_Function __vtbl_20TypeInfo_StaticArray __vtbl_25TypeInfo_AssociativeArray __vtbl_3gcx2GC __vtbl_3gcx6GCLock __vtbl_3std10moduleinit15ModuleCtorError __vtbl_3std11outofmemory20OutOfMemoryException __vtbl_3std3utf12UtfException __vtbl_3std3utf8UtfError __vtbl_3std5array16ArrayBoundsError __vtbl_3std6string15StringException __vtbl_3std6thread11ThreadError __vtbl_3std6thread6Thread __vtbl_6Object __vtbl_6object5Error __vtbl_8TypeInfo __vtbl_9ClassInfo __vtbl_9Exception __wargv __wenviron __wenvptr __win32_faterr __win32_stderrmsg __winmajor __winminor __winver __wpgmptr __xc_a __xc_z __xi_a __xi_z __xp_a __xp_z __xt_a __xt_z _abort _calloc _close _edata _end _errno _exit _fclose _fegetenv _fesetenv _fflush _fgetc _findfirst _findnext _flushall _fprintf _fputc _free _gc_init _gc_term _isatty _itoa _lseek _main _mainCRTStartup _malloc _mbtowc _memchr _memcmp _memcpy _memicmp _memmove _memset _no_catch_exceptions _printf _raise _read _realloc _remove _sbrk _setvbuf _signal _sprintf _strcat _strchr _strcmp _strcpy _strdup _strlen _strtold _tolower _ultoa _unmangle_ident _unmangle_pt _vfprintf _vprintf _vsprintf _wcscpy _wcslen _wctomb _write roundto0 ---------------- So I either the map file is wrong (or I misunderstood it), the linker is not stripping out 'unreferenced' functions, or there are many more referenced functions than you suspected. -- Derek (skype: derek.j.parnell) Melbourne, Australia "Down with mediocracy!" 7/04/2006 9:39:07 AM |
Copyright © 1999-2021 by the D Language Foundation