(MSVCRT) _iob disappeared?

(MSVCRT) _iob disappeared?

• Brian Scott

  Can you tell me what you want with the _iob FILE table Usually there is no need to access this table, also its not public and for internal use only.

  Also there might be a trick to access the _iob FILE array. stdin is always at &_iob[0]...

  
  
  

• egady1

  Error 1 error LNK2001: unresolved external symbol _iob main.def

  In my def, I'm redirecting this export as such:

  _iob=MSVCR80._iob

  I also tried:

  _iob=MSVCRT._iob

  
  

• boer

  The library I'm building is being used as a "proxy" if you will for API monitoring/research purposes. I have to handle all exported functions from the original. What gets me is the fact these old internal symbols (_iob, _acmdln, etc) are actively used in Windows Vista applications...
  

• kalaria

  It is definitely still there - exactly what kind of errors/behavior are you seeing
  
  

• Sommarafton

  Ayman hates an unanswered thread and brings in the troops to get it resolved. I'm going to mark this thread unanswered, my apologies to everybody that got the answer assigned originally...
  
  Ayman: you're a fantastic program manager and a shining example of a great MSFT employee. And thanks for the answers...
  
  
  
  

• schow

  The exported name for _iob is __iob (two underscores); that's the name you need in the .def file.
  
  
  

• Kimberly Blair

  I've seen the __iob problem as well... I'm trying to make a mixed managed/native C++ wrapper for a static third party library. Upon linking, I get errors saying various symobls are already defined.
  
  E.g. libcmt.lib(mlock.obj) : error LNK2005: __unlock already defined in MSVCRTD.lib(MSVCR80D.dll)
  
  I get over 20 errors... so then I tried changing the linker settings to "Ignore Specific Library" for libcmt.lib. Then when I build I get rid of all the "already defined" errors and instead end up with just:
  
  error LNK2001: unresolved external symbol __iob
  from within the static third party library
  
  So it would seem that __iob is not defined in MSVCRTD.lib... but is defined in libcmt.lib.
  
  It also means I am stuck... how can I link my wrapper
  
  
  
  
  
  
  

• Matt Brunell

  Here's the interesting thing -- It's there!

  dumpbin msvcrtd.lib /all | grep iob

  <snip>
  Symbol name : __iob
  Name : _iob
  Symbol name : ___p__iob
  Name : __p__iob
  Symbol name : ___iob_func
  Name : __iob_func
  <snip>

  
  

• Vikas_purohit

  Rafael Rivera wrote:

  What gets me is the fact these old internal symbols (_iob, _acmdln, etc) are actively used in Windows Vista applications...

  I still don't understand why you need to access this fields directly. They are still internal (undocumented)! When a program links to it it is normal, at least because even this internal (undocumented) gets exported and are used by macros.

  
  
  

• Shun Yamaguchi

  It is not necessary for the developer to access _iob directly for this problem to occur. We're running into the same problem when linking with libs which were compiled under VC 6.
  
  It could be that any lib calling printf() family functions wind up compiling a reference to _iob into the executable/library.
  
  

• fourmi

  Let me try to explain in a different way:
  
  Program A that makes use of _iob is importing from DLL A.
  I'm replacing DLL A with DLL B that proxies requests to DLL A via MSR Detours.
  DLL B has to support everything DLL A did.
  
  Or in another more graphical way:
  
  old: my.exe <-- imports -- _iob (msvcrt.dll)
  new: my.exe <-- imports -- _iob (proxy.dll) <-- imports -- _iob (msvcrt.dll)
  
  Hope that clears things up. By the way, is the above bug acknowledged/reproducable by you guys
  
  
  
  

• gko

  Hello,

  I'm facing exactly the same problem. I need to compile with a library that was compiled using VC 6.0. Of course I have no way to recompile this library as it's part of a product from another company.

  Did someone have a way to avoid this problem I tried to make some stubs, I check in the header file (stdio.h, wchar.h) and so on...

  Many thanks in advance

  Laurent Flahou

  
  
  

• Level7

  MSVC6 references _iob in the stdio.h and wchar.h include files. Using stdin, stdout, stderr, getwchar() or putwchar() creates a reference to _iob in the .lib file. I created a test program that uses _iob:
  
  #include "stdafx.h"
  #include <stdio.h>
  
  // This is how stdin is declared in MSVC6' stdio.h:
  extern "C" extern FILE _iob[];
  #undef stdin
  #define stdin (&_iob[0])
  
  int _tmain(int argc, _TCHAR* argv[])
  {
  // Force a reference to stdin:
  fread(stdin, 0, 0, 0);
  return 0;
  }
  
  When I compile this, I get "error LNK2001: unresolved external symbol __iob". Project + Properties, C/C++, Code generation, Runtime library = Multi-thread Debug (/MTd). Now the program compiles and links without problems.
  
  The problem is clearly caused by the DLL version of the CRT not exporting the __iob symbol. The solution is to statically link the CRT.
  
  
  
  

• mrfatmen

  To resolve the issue, I made stubs in my main code:
  
  ...
  void _acmdln( ) { }
  void __pioinfo( ) { }
  void __badioinfo( ) { }
  ...
  
  The compiler still went through the .def and properly linked my exports to their real outside counterparts. Go figure!
  
• (MSVCRT) _iob disappeared?