This concerns EVERY real game-programmer (no joke)!

Started by
18 comments, last by SmilingBandit 24 years, 6 months ago
How do you set up remote debugging on another networked computer?
Advertisement
Here it is, directly from the MSDN documentation.

Setting Up the Remote Debug Monitor
The remote debug monitor is a small program on the remote target computer. It communicates with

the debugger host and controls the execution of the program you are debugging.

To install the remote debug monitor

On a Windows 95 or NT computer, the remote debug monitor consists of the following files:

MSVCMON.EXE, MSVCRT.DLL, TLN0T.DLL, DM.DLL, MSVCP6O.DLL, and MSDIS110.DLL. For Windows NT only,

the remote debugger also requires PSAPI.DLL. Copy these files to the remote target computer, move

MSVCRT.DLL to the System32 directory, and restart.

After you have configured the connection on both ends, you can begin remote debugging.

To begin remote debugging

Set up a shared directory that both the debugging host machine and the remote target machine can

view.
The shared directory can be on either machine or a network drive. The easiest option is to share

the directory on the host machine that contains the project’s executable file.

Note If you can’t make a shared directory, copy the executable file and any needed DLLs to the

remote target computer. With this method you need to be sure that the executable files and DLLs

are recopied whenever changes are made.

Load the project into the Visual C++ development environment.


From the Project menu, click Settings.
The Project Settings dialog box appears.

Choose the Debug tab.


In the Category list box, select General and set the following items:
Executable for Debug Session Enter the name and path of the executable file as the debugger

host computer sees it.


Working Directory Leave blank.


Remote Executable Path Enter the name and path of the executable file as the remote target

computer sees it.
In the Category list box, select Additional DLLs.
Enter the name and path of any DLLs as the debugger host computer sees them.

Start the remote debugger on the remote target computer.
Find the Visual C++ and select the Visual C++ Debug Monitor icon. Click Connect to start the

connection.

From the Build menu, click Debugger Remote Connection.
Confirm the choices for Platform and Connection or modify them as needed.

Begin debugging.
Hi!

I have another way.
Perhaps a little bit difficult to realize, but...
In my company, before to use multi-monitor-debugging, we used, (and i always use for myself), an Hercules monochrome card to debug, and a monochrom monitor.
Perhaps some of you have already use it to debug, with a debugger...
But we can also use it to see personal infos...
This one works perfectly on Win95 & 98.
It''s simpliest to install, coz'' this card don''t need interrupt to works. it''s only show a mapping of the state of memory in Text-Video-Memory(0xB000).
Of course, we use a library to display text, (or graphics, in fact) on this screen, (write to this adress of 0xB000).
Some problems: it''s slow and perhaps not so easy to find... but if you can find a old card, you''ll never pay a lot!


VL''H.
Why would this concern me? The topic is a few years old now.
William Reiach - Human Extrodinaire

Marlene and Me


That has never happened to me, nor do i believe it affects every (game) programmer with any stretch of the imagination.
quote: Original post by Bracket

*snip*

...
*snip*

As for development - Win2k is wonderful for writing games. Assuming that you want to use uptodate calls (ie. no execute buffers!), the entire API is supported. On top of this, you gain incredible stability (especially when compared with Win98). I''ve recovered from some really nasty crashed apps (due to bad programming on my part), and I rarely (if ever) have to reboot.

As for debugging... I debug over a network, use log files, AND use Win2k''s ability to debug fullscreen apps (although this can still fail, sometimes). There is never just one right answer!



It is nice to have the games more stable on Win2k but the reality of the fact is that Win95 and Win98 will be around for a long time, especially the latter. The guys that are buying the big Athlon computers today run Win98 for games. If you forget to optimize your game for Win98(and remove crashing bugs) you''re going to leave people out in the cold much in the same way that Ultima IX did. Just thought I would chime in. I really think sitting on the cusp of an OS release is a pain in the rear. It almost worth designing for Win2k and waiting 2 years to release so you can save the development effort(not really). *chuckle*

Kressilac
Derek Licciardi (Kressilac)Elysian Productions Inc.
---------------------------
Posted by Gromit:
Why would this concern me? The topic is a few years old now.
---------------------------

It might be that I haven´t invented this topic,
but not every user of this message board is willing to search the posts of the last 200 days to find something similiar.



The Smiling One (:
The Smiling One (:
I have Windows 2K Prof. Ed. But didn''t find another way to debug fullscreen.....does anybody of you know how that is done the way he says???

Dance with me......

http://members.xoom.com/CJdeVos/index.htm

When it comes to remote debugging, I used something that most people wouldn''t think of - connecting the two computers with a parallel cable. I don''t have a hub to network the two computers together!

Anyhow, it worked fine. I had to go to Control Panel - Network.. and specify for TCP/IP to manually provide IP address - then entered something like 111.111.111.1 on one computer, and 111.111.111.2 on the other. Only the last digit can be different between the two computers. I believe I set subnet mask at 255.255.255.1 for both.

Anyhow, after connecting parallel ports with bidirectional cable, run "Direct Cable Connection" on both computers. It is found in Start Menu - Programs - Accessories... it is a program that comes with Windows but is optional... you might have to install it from Control Panel - Add Remove Programs.

Anyhow, that''s it. You should be able to ping the other computer at the specified IP - and if not, you will be able to ping the computer name instead... meaning your computers are networked and can now use remote debugging by following the steps provided at MSDN.

Clay
CJ: I can''t find anyway to debug full screen apps either?

This topic is closed to new replies.

Advertisement