Using the NTU simulator

NTU enables running MMLite and the rest of Microsoft Invisible code as a user more application under Windows NT, Windows 2000, or Windows XP. This is particularly convenient for debugging with Visual Studio.

Contents: building debugging networking.

Building NTU

  • Install either Visual C++ 6.0 or Visual Studio.NET
  • Run vcvars32.bat to set the compiler environment variables

    • To find the vcvars32 file you can use dir, e.g. 

    c:\inv> pushd %ProgramFiles%
c:\Program Files> dir/s/b vcvars32.bat
c:\Program Files\Microsoft Visual Studio\VC98\Bin\VCVARS32.BAT

c:\Program Files> "C:\Program Files\Microsoft Visual Studio\VC98\Bin\VCVARS32.BAT"
Setting environment for using Microsoft Visual C++ tools.
c:\Program Files>popd
c:\inv>

  • Build the i386 debug version. 
    c:\inv> set MMLITE_SDK=c:\inv
c:\inv> nmake TARGETCPU=i386 TARGETTYPE=debug
c:\inv> cd build\i386\debug\bin
c:\inv\build\i386\debug\bin> ntu.exe
> alltests.exe
...

    • Debugging with NTU.

  • You can debug the system by running it under the debugger 
    c:\inv\build\i386\debug\bin> msdev ntu.exe
    Useful commands include Control-C in the console window for dropping into the debugger; View/Debug Windows/Call Stack for the stack; F9 and Alt-F9 for breakpoints; Debug/Threads for looking at the NTU treads (one thread runs the "CPU", one the "network chip", one the "timer", etc. The CPU one is the one that is most interesting as it runs the simulated code). It is often convenient to suspend the timer thread when single stepping so as to avoid jumps to the interrupt routine. The Debug/Threads dialog facilitates that. Note that without timer interrupts some code will not work (e.g. the TCP protocol) so you may want to resume the timer thread occasionally.

    With the debug version of ntu you will get symbols for ntu itself. If you use bigblob.exe that has some common components built in you will get more symbols. To get symbols for loaded programs you need to patch the debugger to receive load notifications from NTU. The file tools/VC_debug_patch/README.TXT explains how. Here is the short story: 

    vcvars32
pushd %MSDEVDIR%\Bin
copy msdev.exe msdev.safe.exe
copy %MMLITE_SDK%\tools\VC_debug_patch\debuglod.dll .
%MMLITE_SDK%\tools\VC_debug_patch\setdll -d:debuglod.dll msdev.exe
popd

    Now when you run 
    msdev ntu.exe
    again you should get symbols for any program you run. For instance try putting a breakpoint into your test program (asm int 3 or rather DebugBreak()) and run it from NTU.
    NOTE: debuglod.dll currently works only with VC6. Support for VS7 will be added later.
  • You can use the network stack and debug it (e.g. put a breakpoint in tcp_input). To make it work, please read on.

    • Using the ethernet from NTU

    The NTU simulator network stack can be used as if it were directly on the network. A special simnic.cob ethernet driver is used to delegate the ethernet packets to the host operating system. Another driver (packet.sys) on the host side forwards raw ethernet packets inside the Windows kernel.

    1. Install second ethernet card and connect it to your network.

      In order for the host Windows protocol stack and the simulator protocol stack not to confuse each other they each should have their own ethernet card. That way they each have their own ethernet address.

    2. Install packet driver.

      PACKET.SYS is the host driver that forwards raw ethernet packets between the actual ethernet and the simulator. The driver is distributed as part of the Invisible Computing Source tree src/drivers/net/packet.

      To install the packet driver right click on "My Network Places" on the desktop, "Properties", right click "Local Area Connection 2", "Properties", click "Install", select "Protocol", click "Add", click "Have Disk", "Browse" to c:\inv\src\drivers\net\packet\ (or wherever you installed the source at), select packet.inf, click "Open", "OK", then "Browse" to the bin\i386\free subdirectory, select packet.sys, click "Open", "OK".

    3. Configure NT

      4. Next make sure NTU uses one network card and the host Windows the other. This is done by enabling only "DDK PACKET Protocol" on one card (the second card) and disabling it on the other.

      Start with the primary card: Right click "My Network Places", "Properties", right click "Local Area Connection", "Properties", clear the checkbox for "DDK PACKET Protocol" (leave all other checkboxes alone), "OK".

      Continue the secondary card: Right click "My Network Places", "Properties", right click "Local Area Connection 2", "Properties", check the checkbox for "DDK PACKET Protocol" and clear all other checkboxes, "OK".

    4. Reboot.

      5. The packet.sys driver does not work without a reboot.

    5. Run NTU. It now has access to the network.

      6. The MMLite protocol stack configures itself from a DHCP server. Most networks have one running.

    6. Run something that uses the network on MMLite.

      7. Programs that use the network bind to protocol.cob. If it wasn't already loaded it will be loaded. At that time it will configure itself using DHCP. For example httptest.exe starts a web server. Try browsing from another machine. Ping.exe exercises some lower level networking. Pinging into and out fof the machine works if the network is configured as expected.