Playing with the stack

• Download demo project - 406 Kb

Introduction

In this essay I am going to show you how the most commonly used C++ compilers (MSVC and Borland) use the stack. Beginners will learn how the stack is used, what the function stack frame is, what the stack frame pointer is and how to use this information in order to get a function stack trace. I hope that the more advanced readers will find some interesting information, too. As an example, a simple class named StackDumper is described.

The class StackDumper has a method that browses the thread's stack and allows you to save in a text file the names (or addresses in the worst case) of all functions executed before the foo is called. As a side effect of this functionality you will be able to ask the StackDumper whether foo is called from foo1.

The task became a little bit complicated by my intention to create a class that is not dependent on any particular compiler. If you download the article demo you will find three projects - for MSVC++ 6, for Borland C++ 5.02 and for Borland C++ Bulder 6. If you are using the VC++ compiler there is an easy and already described way to implement this functionality. John Panzer has published in the C/C++ Users Journal, January 1999, his essay "Automatic code Instrumentation". In brief, he uses the /Gh compiler switch to force the compiler to generate a call to a _penter function at the start of each client function. From inside _penter the address of the caller is retrieved and stored in a parallel stack. It also records the function entry time. Afterwards the original return address of the caller is replaced by the address of a user function. This function is used for profiling purposes. When it is called it records the function exit time and restores the original return address of the caller. This is the main idea. You can download the essay from here.

Obviously this approach uses a Microsoft-specific compiler switch. Due to the parallel stack support special attention should be paid to the case where an exception occurs in one of the profiled functions. The compiler generates a hidden call to the _penter function in all user functions, which is not very flexible because you may not want to collect information about every function. The same functionality can be implemented by the well known concept of stack backtrace. The idea is to use the stack frame that each function builds on the stack to trace the calling sequence. This approach is compiler independent (at least it works with both MSVC and Borland compilers), but it also imposes some limitations. Most compilers provide options to compile a function without prolog and epilog code. For example functions declared with __declspec(naked) attribute will be compiled by MSVC++ and Borland C++ compilers without prolog and epilog code. The same effect can be reached by specifying some compiler options for optimizations. For example the /Oy switch in the Microsoft compiler suppresses the creation of frame pointers on the call stack. In this essay I take for granted that the program is compiled without any optimisations or "special" compiler switches.

1. How the stack is used?

1.1. Stack frame and frame pointer

Here is a brief explanation for those of you who are not familiar with the way the stack is used during function calls. The more advanced readers can skip this section. When a function is called its arguments are pushed onto the stack in an order that depends on the calling convention. Then the call instruction is executed. It pushes the return address onto the stack. The first instruction of the function is push ebp - the base pointer is pushed. The stack pointer is moved to the ebp register, then the esp register is decremented to make room on the stack for the local variables of the function. So for every called function the following information is built on the stack:

Figure 1.

This information is called the "stack frame". The register ebp has a special meaning. It is called the "frame pointer". The frame pointer is initialized at the function start by the standard prolog code and stays unchanged during function execution. The value of the previous function frame pointer is restored when the current function exits (epilog). How is the frame pointer used? The compiler uses the frame pointer to refer to local variables and parameters of a function (if any).

• *(ebp) is the value of the frame pointer of the caller;
• *(ebp + 4) is the return address (the place in the caller body where execution will continue after the callee returns);
• *(ebp + 4 + 4 * i) is the value of i-th function argument (1 based, assuming that each argument takes 4 bytes);
• *(ebp - offset) refers to local variables.

You can see this operation in the following simple example:

int func(int nArg1, int nArg2)
{
    int n[3];

    return nArg1;
}

int main()
{
    func(0, 1);

    return 1;
}

The Borland C++ 5.02 compiler generates the following assembly code (__cdecl calling convention - the arguments are pushed on the stack from right to left, the caller cleans the stack. More information about calling convention can be found here):

Dissassembly of main:

00401110 55               push    ebp           <--store the ebp register
                                                    on the stack
00401111 8B EC            mov     ebp, esp      <--current stack pointer
                                                    in ebp
00401113 6A 01            push    1             <--the arguments of func
                                                    are pushed on the stack
                                                    from right to left
00401115 6A 00            push    0
00401117 E8 EC FF FF FF   call    func          <--this call pushes the
                                                    return address (0040111C)
                                                    on the stack
0040111C 83 C4 08         add     esp, 8        <-- __cdecl calling
                                                    convention
                                                    => caller has to clean
                                                    the space that arguments
                                                    used on the stack. Every
                                                    push decrements the stack
                                                    pointer and every pop 
                                                    increments it by the size
                                                    of the operand. Two ints
                                                    are pushed on the stack
                                                    => the stack pointer
                                                    has to be increased by 8
0040111F B8 01 00 00 00   mov     eax, 1        <-- the return value of
                                                    main goes in eax
00401124 5D               pop     ebp           <-- ebp is restored
00401125 C3               ret

Dissassembly of func:

00401108 55               push    ebp              |<-- prolog. 
00401109 8B EC            mov     ebp, esp         |

0040110B 83 C4 F4         add     esp, -0x0c       <-- make room for 3 * 4
                                                       bytes for the local
                                                       variable n on the 
                                                       stack
0040110E 8B 45 08         mov     eax, [ebp+0x08]  <-- move the return
                                                       value (nArg1) to eax

00401111 8B E5            mov     esp, ebp         |<-- epilog. epb
                                                        contains the caller
                                                        frame ptr
00401113 5D               pop     ebp              |
00401114 C3               ret                      

1.2. Callstack

It is not very hard to see how the stack frame of a function can be used to get the caller address of this function. As I have mentioned before *(ebp + 4) points to the return address of the function. This address is inside the body of the caller.

1.2.1. How to get the starting address of the caller?

Approach 1: Prolog searching

We suppose that all functions are compiled with a prolog and an epilog. Having an address inside the function, we just have to search for the byte sequence 55 8B EC. As you can see from the dissassembly above these are the opcodes of the prolog. Let's call them the "prolog signature". Unfortunately there is a problem. The same sequence of bytes could appear in an instruction as an operand. For example the instruction mov eax, EC8B55h has the following instruction encoding: B8 55 8B EC 00. Obviously when we are searching the prolog signature byte by byte we will find the signature somewhere inside the mov instruction.

Note: In my experience the method of searching the prolog signature in most cases works fine. To keep things simple you can skip the next section. Note end.

Well, I don't have an elegant solution to the above problem. For that reason I am going to kill a mosquito with a nuclear bomb :-).

Approach 2: Backwards disassembling

Given an address inside the body of a function, it is easy enough to find the address of the previous instrucion. This task cannot be solved without knowing the instruction format. We need a disassembler to do this. You can find in the source a function called FindAddressOfprevInstruction:

#define  MAX_INTEL_INSTRUCTION_LEN 15
DWORD FindAddressOfprevInstruction(DWORD EIP, PUCHAR instr)
{
    DWORD Addr = EIP-MAX_INTEL_INSTRUCTION_LEN;
    DWORD prevAddr;
    unsigned long res;
  
    do
    {
        prevAddr = Addr;
        res = Disasm32(&Addr, instr);
    } while(Addr < EIP);
    
    EIP=prevAddr;
    return EIP;
}

I think this function is straightforward. Having this function it is easy to find the prolog signature in a more precise way - you just have to disassemble backwards until you find the prolog signature.

1.2.2. Tracing the stack

As you can see from Figure 1. every functions stack frame contains a pointer to the callers frame which contains a pointer to its caller frame and so on. In fact we have a list of stack frames which can be used to find the callstack of every called function. But still there is an important question: When do we have to stop stack browsing, or, in other words, where does this list begin? I think we can find the answer if we take a look at the process and thread starting routines which resides in kernel32.dll.

When Windows creates a process and its main thread it performs an internal call to the CreateProcess API. CreateProcess in turn invokes an internal routine in kernel32.dll named BaseProcessStart. Here is the dissasembly (under the condition that you have kernel32.pdb):

KERNEL32!BaseProcessStartThunk:
77e8d2e4 xor     ebp,ebp    <-- Look here!
77e8d2e6 push    eax
77e8d2e7 push    0x0        <-- This can be interpreted as a return address
KERNEL32!BaseProcessStart:
77e8d2e9 push    ebp        <-- This is a normal stack frame. But the
                                previous frame ptr is zeroed a few lines
                                above
77e8d2ea mov     ebp,esp
77e8d2ec push    0xff

...snip...

77e8d323 call    dword ptr [ebp+0x8] <-- call the entry point of our 
                 process(for example mainCRTStartup)
77e8d326 jmp     KERNEL32!BaseProcessStart+0x3d (77eb6624)

Similar things are happening in each call to the CreateThread API:

KERNEL32!BaseThreadStartThunk:
77e964cb xor     ebp,ebp
77e964cd push    ebx
77e964ce push    eax
77e964cf push    0x0
KERNEL32!BaseThreadStart:
77e964d1 55               push    ebp
77e964d2 8bec             mov     ebp,esp
77e964d4 6aff             push    0xff

...snip...

77e9651d ff750c           push    dword ptr [ebp+0xc] <-- push the argument
                                                          to ThreadFunc
77e96520 ff5508           call    dword ptr [ebp+0x8] <-- DWORD WINAPI 
                                                          ThreadFunc(LPVOID);
77e96523 50               push    eax
77e96524 e805000000       call    KERNEL32!ExitThread (77e9652e)
77e96529 e923f10000       jmp     KERNEL32!BaseThreadStart+0x81 (77ea5651)

Judjing from the examples above I think we can conclude that stack frames tracing can stop when either the return address or the old ebp turns to zero.

1.3. "Called from" functionality

Up to now we know how to create a callstack list (a list of addresses of functions). I would like to say a few words about the following question: Is it possible to implement a method that will allow the following C++ functionality?

retType foo(arguments)
{
    if (foo_is_called_from_functionX) 
        doThings
    else
        doOtherThings

    return whateverHasToBeReturned
}

Two additional questions arise here:

1.3.1 Do we need such a functionality?

This functionality could be considered as a new type of C++ runtime information. Since it is not implemented in the C++ standard it is probably useless... In my opinion this is a theoretical question and it should be the subject of a separate discussion.

1.3.2. How to implement this functionality?

Since we know the call stack of foo it may seems trivial to browse the caller addresses searching for the address of functionX. Unfortunately things are not so simple. The main difficulty is how to get the address of functionX. functionX may be a class member (virtual or nonvirtual) function. There is no way to get the "real" address of a function from inside a C++ program. By "real address" I mean the relative virtual address where the compiler placed the function body. In most cases when you get a function address from inside a C++ program it does not appear to be a real address, but rather an address in some virtual or thunking table. On the other hand it is definitely clear that callstack addresses are real addresses. So what can we do in this case? The only simple solution I have found is to use function names instead of their addresses. This is because there is a relatively easy way(s) to find the address of a function, having given its name. This will allow us to implement the above function as follows:

retType foo(arguments)
{
    if (IsCalledFrom("functionX") || IsCalledFrom("A::member1"))
        doThings
    else
        doOtherThings

    return whateverHasToBeReturned
}

Now the question is how to find the address of a function given its name. There are two common ways to do this:

• The development environment provides libraries that allow working with symbolic information. For example Microsoft provides the debug help library named DbgHelp (prior to Windows 2000 the library was known as Image Help Library). The library contains functions for working with symbolic information, for example SymGetSymFromName, SymFromName etc. As an example of using the DbgHelp library here is the function getFuncInfo you can find in the source. As far as I know, Borland provides a similar library named Borland Debug Hook Library, that can be used to extract information from Borland debug symbol (.tds) files. Unfortunatelly there is not much information on the net about how to use this library. You can download it from here.

• Working with .map files. Both Microsoft VC++ and Borland C++ compilers are able to generate map files. Generally speaking map files are text files that contain information about functions (and variables) in a module and their addresses. For example here is a snippet of a .map file generated by the Borland C++ 5.02 compiler:

 0001:000006F5      StackDumper::DumpStack(unsigned int)
 0001:00000694      StackDumper::GetCallerAddr(long)
 0001:000006C5      StackDumper::GetFuncAddr(unsigned long)
 0001:000005FC      StackDumper::StackDumper()
 0001:00000639      StackDumper::~StackDumper()

The important thing here is that the addresses are logical addresses. For example 0001:00000639 means that the destructor StackDumper::~StackDumper() resides in the first section in the PE file at offset 0x639 in that section. In the source you can find a simple function (written by Matt Pietrek) that converts linear addresses to logical addresses. Using this function you can convert the addresses from the stack trace into logical addresses that can be found in the map file. Having the logical address you just have to parse the .map file in order to find the function name. As a conclusion I have to say that I don't have any idea about how to implement the IsCalledFrom functionality in your release builds - when you have neither debug information nor a map file generated (or you don't want to distribute such information with your program).

2. Exit thunks

In this section I will describe how to use the stack frame information in order to implement exit thunks.

An exit thunk is a function that is invoked immediately after the ret instruction of the function for which the thunk is installed. Exit thunks can be used for example in profiling applications. Here they are implemented as just another example of how to use the stack frame information.

The idea is very simple - in order to install an exit thunk we just have to declare a local variable: StackDumper varName(true) (true means "use exit thunk") in the body of the function for which we want to install the thunk. The destructor StackDumper::~StackDumper() first saves the original return address of the function(i.e. foo) where StackDumper is declared in a static local variable in StackDumper. Afterwards it replaces the return address of foo with the address of the ExitThunk. This causes the ret instruction of foo to pass the control to the beginning of the ExitThunk. (Note that the destructor is the correct place to perform this replacement. If we replace the function return address in the constructor (for instance) subsequent calls to the DumpStack function will generate erroneous stack trace information).

This is not a common function call - the ret instruction has popped the return address from the stack (which is now the address of ExitThunk) and a jump is performed. So if ExitThunk builds a standard stack frame this frame will not contain a return address. Another problem is that ExitThunk has to be "invisible" - it should not touch the registers, especially eax - where the function foo has placed its return value (if any). If ExitThunk is a standard function it will have something like this at the beginning(MSVC, Debug):

50:   void main()
51:   {
004010F2 55                   push        ebp
004010F3 8B EC                mov         ebp,esp
004010F5 6A FF                push        0FFh
004010F7 68 F0 30 41 00       push        offset $L49591 (004130f0)
004010FC 64 A1 00 00 00 00    mov         eax,fs:[00000000] <---Look here:
                                                            The eax register
                                                            is changed and 
                                                            there is nothing
                                                            you can do!!!
00401102 50                   push        eax
00401103 64 89 25 00 00 00 00 mov         dword ptr fs:[0],esp
...

You see that ExitThunk could not be a normal function.This is the reason for which this function must be declared naked. From MSDN: "For functions declared with the naked attribute, the compiler generates code without prolog and epilog code. You can use this feature to write your own prolog/epilog code using inline assembler code.". Fortunately the three compilers I have tested the examples with (BC++ 5.02, BCB6, MSVC6) support naked function calls. (For Borland C++ 5.02 users this is probably a surprise. This was not documented. ;-))).This is the solution to the above mentioned problems. So the implementation of ExitThunk could be as follows:

/* static  */
void __declspec(naked) StackDumper::ExitThunk()
{
    __asm
    {
        push ebp
        mov ebp, esp
        sub esp, 4 //make room for one local variable

        pushad 
    }

    DoTheWork();

    long temp;
    temp = origRetAddr;
    __asm
    {
        popad
        mov esi, temp
        mov esp,ebp
        pop ebp
        jmp esi //I don't have return value on the stack

                  -> can not use ret here.
    }
}

Well, that's all folks!

Acknowledgements

I would like to thank mamaich for his help on disassembling issues!

Note about source compilation. In order to compile inline assembler source code with Borland C++ 5.02 you will need Turbo Assembler (tasm32.exe). tasm32.exe is not included in the Borland C++ 5.02 distribution. If you have BC++ Builder you will find tasm32.exe in the bin folder.

You must Sign In to use this message board.

FAQ    Noise Tolerance Very HighHighMediumLowVery Low   Layout Expand Posts & RepliesThread ViewNo JavascriptNo JS + Preview   Per page 102550

Msgs 1 to 21 of 21 (Total in Forum: 21) (Refresh) FirstPrevNext

Omit Frame Pointer (FPO) and stack walk yalmin 6:07 19 Dec '07   I have a module use StackWalk64 to walk the stack when there is an excpetion occurred. There maybe some client modules created with FPO. What will happen under this situation? Will StackWalk64 failed? Any suggestion on how to handle this situation? Thanks. Sign In·View Thread·PermaLink check like 3 levels of GetCallerAddr patrick.steal 8:25 23 Nov '07   Hi, Is it possible to find 3 levels of caller addresses like: Function1(); //calls function2 Function2(); //calls function3 Function3(); //calls function4 Function4(); //logs now lets say that Function1() is located at addr: 0x1000056, then is it possible to walk the stack backwards in Function4() and find if 0x1000056 has made a call with this class? I found that you could do something like this: BOOL WalkStack() { // Get stack basepointer from EBP register with inline ASM DWORD dwEBP; __asm { mov dwEBP, ebp; } BOOL EBP_OK = TRUE ; // Walk stack backwards do { if( (DWORD)dwEBP & 3 ) EBP_OK = FALSE ; // Validate EBP width is DWORD if( EBP_OK && IsBadReadPtr( (void*)dwEBP, 8 ) ) EBP_OK = FALSE ; // Validate pointer previous EBP = DWORD at base+4 thus size=8) if( EBP_OK ) { BYTE* caller = *((BYTE**)dwEBP + 1); // Build pointer to previous stack base pointer. dwEBP = *(DWORD*)dwEBP ; // Get previous caller's stack-base address if (!IsBadReadPtr((void*) caller,4)){ // Validate pointer for DWORD if ((DWORD)caller == 0x5E980) { //g_Log.Log("Function called!"); return TRUE; // our module-of-interest reached. Return true } else { //g_Log.Log("stacktrace-> %s",chGetModuleName((DWORD)caller)); } } } } while( EBP_OK ) ; return FALSE; // module-of-interest not found. return false } char* chGetModuleName(DWORD dwAddress) { MODULEENTRY32 lpme= {0}; DWORD dwBase=0; BOOL isMod=0; static char strModName[256]="unknown"; char strFileName[256]=""; DWORD PID=GetCurrentProcessId(); int isFound=0; HANDLE hSnapshotModule=CreateToolhelp32Snapshot(TH32CS_SNAPMODULE ,PID); if (hSnapshotModule) { lpme.dwSize=sizeof(lpme); isMod=Module32First(hSnapshotModule,&lpme); while(isMod) { if ((dwAddress>=(DWORD)lpme.modBaseAddr) && (dwAddress<(DWORD)(lpme.modBaseAddr + lpme.modBaseSize))) { strcpy(strFileName,lpme.szExePath); PathStripPath(strFileName); sprintf(strModName," %s[0x%08x]",strFileName,dwAddress); break; } isFound++; isMod=Module32Next(hSnapshotModule,&lpme); } } CloseHandle(hSnapshotModule); return strModName; } now the poblem with this code is that it walks the whole stack backwards and also sometimes it doesnt seem to work, it just crashes the application, u got any advice as to how i could maybe limit the walk-back to like 3 levels? so that it only checks the 3 last callers instead of the full stack? Thanks in advance. Sign In·View Thread·PermaLink Nice Article Vinay.Net 13:23 18 Aug '07   nice article with some good humor "I am going to kill a mosquito with a nuclear bomb " Sign In·View Thread·PermaLink An question ramesh_hp2006 22:34 8 Jul '07   Your article mentions of how to get stack information when the executable is in debug mode. Can I know how to get stack information when the executable is in release mode? Basically I need to get following informations, 1. Function being called 2. Input parameters being passed 3. Output from the function 4. Result of the function call, success/failure Is it possible to get these informations from the stack using a release mode executable? Please advise! Sign In·View Thread·PermaLink Re: An question Paul Sanders (AlpineSoft) 9:34 26 Oct '07   I can't give you chapter and verse on this, because it's too big a subject and you don't provide any context, but one thing you should definitely do is to turn off 'Whole Program Optimisation' (/GL), as, with this enabled, the compiler tends to shortcut the normal parameter passing conventions. Another one to watch out for is 'Omit Frame Pointers' (/Oy) for the same reason, and 'Inline Function Expansion' and 'Enable Intrinsic Functions' might also catch you out. If you can sort out the above, the return address and parameters passed in should be accessible immediately on entering the function via offsets from EBP, and the compiler puts the function return value in EAX just before it returns. The function being called is not on the stack anywhere, but if you call another function from within it then it will be. To learn more about this sort of stuff, write a small program with 2 or 3 function calls and walk it through in the debugger in 'Show disassembly' mode. Paul Sanders http://www.alpinesoft.co.uk Sign In·View Thread·PermaLink crash when using VS20005 in release mode dmihailescu 7:50 18 Jan '07   it crashes only in release mode inside GetFuncAddr in the loop regardless of the _USE_DISSASEMBLER value. any ideeas? Debug is just fine. Sign In·View Thread·PermaLink Windows CE (Pocket PC)? Tony Kmoch 2:19 5 Sep '05   Does anyone tried something similar on Windows CE OS? I am not able to make there the callstack at all! Tony Sign In·View Thread·PermaLink 1.00/5 (1 vote) Re: Windows CE (Pocket PC)? Member 1834772 6:11 28 Oct '08   Hi Tony, Did you manage to get any answers on this? I also need to view the stack on "Windows Mobile"... Thanks, Paz Sign In·View Thread·PermaLink Question about moving the stack pointer bururu@rocketmail.com 5:21 28 Jul '05   Why does the stack pointer only get decremented by 8? Does it not need to, "allocate" space for the return address. The only thing I can think of is this is part of the call instruction. int arg1 = 4 bytes int arg2 = 4 bytes return add = 4 bytes I am referring to this part of the aricle: Dissassembly of main: 00401110 55 push ebp 00401111 8B EC mov ebp, esp 00401113 6A 01 push 1 (4 bytes) 00401115 6A 00 push 0 (4 bytes) 00401117 E8 EC FF FF FF call func (RA is pushed - 4 bytes) 0040111C 83 C4 08 add esp, 8 (ESP now points to RA) Great article btw Sign In·View Thread·PermaLink Re: Question about moving the stack pointer Dieshbag 13:43 11 Jan '06   CALL Instructions are balanced by a RET. PUSH'ed arguments are balanced by an ADD ESP, ## in __cdecl 00401110 push ebp 00401111 mov ebp, esp 00401113 push 1 // These are arguments 00401115 push 0 // These are arguments 00401117 call func // Pushes address of next instruction 00400000 ret // Inside function, pop's next instruction into EIP 0040111C add esp, 8 // This takes off the two arguments push'ed Sign In·View Thread·PermaLink Thumbs up! Ivo Ivanov 19:25 31 Oct '02   Chavdare, Well done! There are not many guys who would dare to shed some light on this very interesting programming area. Thanks, (Dawaj wse taka!) Ivo Sign In·View Thread·PermaLink Re: Thumbs up! Anthony_Yio 19:48 31 Oct '02   Fantastic article. Sign In·View Thread·PermaLink Re: Thumbs up! Ernest Laurentin 7:37 1 Nov '02   Really good comment! but his name is 'Chavdar'. Excellent work! Sign In·View Thread·PermaLink ebp Goran Mitrovic 14:31 31 Oct '02   You should probably also say a few words about omitting the ebp frame pointer in release builds. It's pretty unnecessary since all variables can be accessed via esp. - Goran. Sign In·View Thread·PermaLink Re: ebp Chavdar Dimitrov 23:58 4 Nov '02   Hello, Frame pointer omission is subject of source code optimization. I think this is another story and should not be discussed in my article. Moreover there is an excellent article on this topic in the MSDN: "Developing Optimized Code with Microsoft Visual C++ 6.0" by Martin Heller. Regards! Chavdar Sign In·View Thread·PermaLink dbghelp.dll Taka Muraoka 13:56 31 Oct '02   Cool article. But what's the difference between the dbghelp.dll you supplied (719,360 bytes, version 6.0.17.0) and the one I found in my system32 directory (163,088 bytes, version 5.0.2195.1)? I wasn't able to run with the latter - it couldn't find SymFromName() in dbghelp.dll Sign In·View Thread·PermaLink Re: dbghelp.dll dsr9996 12:02 12 Jun '03   Copy over the bad dll in system32 with the good one, but beware that System File Protection may defeat you. If it does, look at this site for how to copy the dll so SFP doesn't just set it right back to the old one; http://wint.virtualplastic.net/showtweak.php?tweak_id=45 I used the safe mode + command prompt method + copy good dll over _all_ old bad ones (probably at least three of them on system, in system32, system32\dllcache, and system32\servicepackfiles). Good luck! Sign In·View Thread·PermaLink Small suggestion Giles 5:47 31 Oct '02   Good article. Just a small suggestion, could you have a look at the formatting, as you need quite a large monitor to read this easily. Thanks, Giles Sign In·View Thread·PermaLink Re: Small suggestion Andreas Saurwein 14:31 31 Oct '02   Did'nt I read a similar comment on another article already? Hmmm... Seems that your boss didnt grant you a new monitor still I keep submitting “VB” as a Priority-1 bug, but apparently no one here knows how to fix it. Nick Hodapp, Semicolon Sign In·View Thread·PermaLink Re: Small suggestion Giles 0:20 1 Nov '02   Andreas Saurwein wrote: Did'nt I read a similar comment on another article already? Hmmm... Well noticed. Thinking about it, was it one of yours? Saying that I do have a 21 inch monitor here at work, and its still difficult to fit it. I need an even bigger monitor. I see apple to a 24 inch wide screen TFT, which looks great. :drool: Sign In·View Thread·PermaLink 2.00/5 (1 vote) Thanks for the great article dessi 4:14 31 Oct '02   I have always had questions about the inner workings of the stack. Thanks for taking the time to write a great article!! Sign In·View Thread·PermaLink 3.13/5 (8 votes)

Last Visit: 21:28 21 Nov '09     Last Update: 21:28 21 Nov '09 1