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.

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.

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.

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.

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.

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.

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?

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

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.

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