Problem with Debugger/IDE in VC++6 Pro, NEED HELP PLEASE 
Author Message
 Problem with Debugger/IDE in VC++6 Pro, NEED HELP PLEASE

Hi All,

I'm having a strange problem with my project. My problem is that
when I want to bebug my application (MFC SDI app) and select
for example 'run to the cursor" option, de{*filter*} will start but it
will go into disassembly window and I will get he following message:
"User breakpoint called from code at 0x77f9eea9" Now if I go
back to my source view and hit "F10" key to continue it will go back
to the disassembly window, why ? I don't want it to go into disassembly
window. This problem seems to be happening only in one of my
projects. I don't have anybreak points booksmarks enabled .
Can anyone tell me what am I doing wrong ? Is my project corrupted ?

A bit more about my environment:

at home:

VC++ 6 Pro + SP4 installed. This is where I created my project a while ago,
yesterday I took the project with me to work where I have VC++6 Entr. SP3
and I spend some time coding and debugging just fine. Then I got home
did a bit more coding and try to debug and got that problem

Thanks for your help..

Peter



Wed, 30 Apr 2003 03:00:00 GMT  
 Problem with Debugger/IDE in VC++6 Pro, NEED HELP PLEASE

Quote:

> Hi All,

> I'm having a strange problem with my project. My problem is that
> when I want to bebug my application (MFC SDI app) and select
> for example 'run to the cursor" option, de{*filter*} will start but it
> will go into disassembly window and I will get he following message:
> "User breakpoint called from code at 0x77f9eea9" Now if I go
> back to my source view and hit "F10" key to continue it will go back
> to the disassembly window, why ? I don't want it to go into disassembly
> window. This problem seems to be happening only in one of my
> projects. I don't have anybreak points booksmarks enabled .
> Can anyone tell me what am I doing wrong ? Is my project corrupted ?

It's a crash, typically something like an assert in the libraries.  Instead of
hitting F10 to continue you should look at the stack window and find the part of
your code that caused the crash down in the library.  The problem is usually
with a parameter you passed, and you can see who passed what by clicking on your
code in the stack window.

--
Scott McPhillips [VC++ MVP]



Wed, 30 Apr 2003 03:00:00 GMT  
 Problem with Debugger/IDE in VC++6 Pro, NEED HELP PLEASE

Quote:

> > Hi All,

> > I'm having a strange problem with my project. My problem is that
> > when I want to bebug my application (MFC SDI app) and select
> > for example 'run to the cursor" option, de{*filter*} will start but it
> > will go into disassembly window and I will get he following message:
> > "User breakpoint called from code at 0x77f9eea9" Now if I go
> > back to my source view and hit "F10" key to continue it will go back
> > to the disassembly window, why ? I don't want it to go into disassembly
> > window. This problem seems to be happening only in one of my
> > projects. I don't have anybreak points booksmarks enabled .
> > Can anyone tell me what am I doing wrong ? Is my project corrupted ?

> It's a crash, typically something like an assert in the libraries.  Instead of
> hitting F10 to continue you should look at the stack window and find the part of
> your code that caused the crash down in the library.  The problem is usually
> with a parameter you passed, and you can see who passed what by clicking on your
> code in the stack window.

> --
> Scott McPhillips [VC++ MVP]

Hi Scott,

Thanks for your replu, I'm not sure I understand you, there isn't a problem with my code
I believe there is something wrong either with my project file or the IDE. I didn't make
any changes to my code, I just compiled and debugged my project at work zipped
the code took it home unzipped and went straight for the {*filter*}, now I'm in trouble...

It doesn't really matter where I set my break point or where I position my cursor in the code
and enter de{*filter*} I always get that dissassembly window and I'm stuck there with that
message box...

Peter



Wed, 30 Apr 2003 03:00:00 GMT  
 Problem with Debugger/IDE in VC++6 Pro, NEED HELP PLEASE
Quote:


> > > I'm having a strange problem with my project. My problem is that
> > > when I want to bebug my application (MFC SDI app) and select
> > > for example 'run to the cursor" option, de{*filter*} will start but it
> > > will go into disassembly window and I will get he following message:
> > > "User breakpoint called from code at 0x77f9eea9" Now if I go
> > > back to my source view and hit "F10" key to continue it will go back
> > > to the disassembly window, why ? I don't want it to go into
disassembly
> > > window. This problem seems to be happening only in one of my
> > > projects. I don't have anybreak points booksmarks enabled .
> > > Can anyone tell me what am I doing wrong ? Is my project corrupted ?

> > It's a crash, typically something like an assert in the libraries.
Instead of
> > hitting F10 to continue you should look at the stack window and find the
part of
> > your code that caused the crash down in the library.  The problem is
usually
> > with a parameter you passed, and you can see who passed what by clicking
on your
> > code in the stack window.

> Hi Scott,

> Thanks for your replu, I'm not sure I understand you, there isn't a

problem with my code

Quote:
> I believe there is something wrong either with my project file or the IDE.
I didn't make
> any changes to my code, I just compiled and debugged my project at work
zipped
> the code took it home unzipped and went straight for the {*filter*}, now I'm
in trouble...

> It doesn't really matter where I set my break point or where I position my
cursor in the code
> and enter de{*filter*} I always get that dissassembly window and I'm stuck
there with that
> message box...

So what does the call stack say? has the de{*filter*} broken within one of your
functions, or one of the library functions?
You say you zipped the files up and transferred the project to a second
machine; did you (a) remember the debug information (.pdb) and (b) maintain
pathnames to be the same?


Fri, 02 May 2003 03:00:00 GMT  
 Problem with Debugger/IDE in VC++6 Pro, NEED HELP PLEASE

Open the output window. There will be a message there telling
you what is wrong. It will probably say something about corrupted
memory, or illegal parameters to one of the memory freeing
functions.

Quote:


> > > Hi All,

> > > I'm having a strange problem with my project. My problem is that
> > > when I want to bebug my application (MFC SDI app) and select
> > > for example 'run to the cursor" option, de{*filter*} will start but it
> > > will go into disassembly window and I will get he following message:
> > > "User breakpoint called from code at 0x77f9eea9" Now if I go

...

Quote:
> Hi Scott,

> Thanks for your replu, I'm not sure I understand you, there isn't a problem with my code

That's incredible confidence. I strongly suspect that you are wrong
and that there _is_ something wrong with your code. You may want
to try running your code under BoundsChecker or Purify to try and
track down the problem.

--
.Bruce Dawson, Humongous Entertainment (we're hiring).
http://www.*-*-*.com/
Send job applications by e-mail, post technical questions
to the newsgroups please. Thanks.



Fri, 02 May 2003 03:00:00 GMT  
 Problem with Debugger/IDE in VC++6 Pro, NEED HELP PLEASE
I don't have any *.pdb files and the whole environment including
files in the project, project settings and project directory didn't change.
I did run the de{*filter*} again and take a close look into Call Stack
Debug window and here is the content:

NTDLL! 77f9eea9()    <-- Arrow Pointer
NTDLL! 77fcd942()
NTDLL! 77fb54c9()
NTDLL! 77fb4732()
NTDLL! 77fa6567()
NTDLL! 77fcabc7()
USER32! 77e1b38d()
USER32! 77e1ad47()
USER32! 77e16ce0()
USER32! 77e27656()
CFrameWnd::GetIconWndClass(unsigned long 13598720, unsigned int 128) line 657 + 20 bytes
CFrameWnd::LoadFrame(unsigned int 128, unsigned long 13598720, CWnd * 0x00000000 {CWnd hWnd=???}, CCreateContext *
0x0012fc4c) line 696 + 16 bytes
CDocTemplate::CreateNewFrame(CDocument * 0x00850040 {CPanzerOOBDoc}, CFrameWnd * 0x00000000 {CFrameWnd hWnd=???}) line
279 + 32 bytes
CSingleDocTemplate::OpenDocumentFile(const char * 0x00000000, int 1) line 132 + 17 bytes
CDocManager::OnFileNew() line 829
CWinApp::OnFileNew() line 29
_AfxDispatchCmdMsg(CCmdTarget * 0x0041e220 class CPanzerOOBApp  theApp, unsigned int 57600, int 0, void (void)*
0x00407166 CWinApp::OnFileNew, void * 0x00000000, unsigned int 12, AFX_CMDHANDLERINFO * 0x00000000) line 88
CCmdTarget::OnCmdMsg(unsigned int 57600, int 0, void * 0x00000000, AFX_CMDHANDLERINFO * 0x00000000) line 302 + 39 bytes
CWinApp::ProcessShellCommand(CCommandLineInfo & {CCommandLineInfo}) line 31 + 30 bytes
CPanzerOOBApp::InitInstance() line 90 + 12 bytes
AfxWinMain(HINSTANCE__ * 0x00400000, HINSTANCE__ * 0x00000000, char * 0x0013253a, int 1) line 39 + 11 bytes
WinMain(HINSTANCE__ * 0x00400000, HINSTANCE__ * 0x00000000, char * 0x0013253a, int 1) line 30
WinMainCRTStartup() line 330 + 54 bytes
KERNEL32! 77e992a6()

I'm running VC++6 Pro (SP4) on Win2K + SP1....could this be the problem ?

Thanks all for trying to help....

Peter

Quote:



> > > > I'm having a strange problem with my project. My problem is that
> > > > when I want to bebug my application (MFC SDI app) and select
> > > > for example 'run to the cursor" option, de{*filter*} will start but it
> > > > will go into disassembly window and I will get he following message:
> > > > "User breakpoint called from code at 0x77f9eea9" Now if I go
> > > > back to my source view and hit "F10" key to continue it will go back
> > > > to the disassembly window, why ? I don't want it to go into
> disassembly
> > > > window. This problem seems to be happening only in one of my
> > > > projects. I don't have anybreak points booksmarks enabled .
> > > > Can anyone tell me what am I doing wrong ? Is my project corrupted ?

> > > It's a crash, typically something like an assert in the libraries.
> Instead of
> > > hitting F10 to continue you should look at the stack window and find the
> part of
> > > your code that caused the crash down in the library.  The problem is
> usually
> > > with a parameter you passed, and you can see who passed what by clicking
> on your
> > > code in the stack window.

> > Hi Scott,

> > Thanks for your replu, I'm not sure I understand you, there isn't a
> problem with my code
> > I believe there is something wrong either with my project file or the IDE.
> I didn't make
> > any changes to my code, I just compiled and debugged my project at work
> zipped
> > the code took it home unzipped and went straight for the {*filter*}, now I'm
> in trouble...

> > It doesn't really matter where I set my break point or where I position my
> cursor in the code
> > and enter de{*filter*} I always get that dissassembly window and I'm stuck
> there with that
> > message box...

> So what does the call stack say? has the de{*filter*} broken within one of your
> functions, or one of the library functions?
> You say you zipped the files up and transferred the project to a second
> machine; did you (a) remember the debug information (.pdb) and (b) maintain
> pathnames to be the same?



Fri, 02 May 2003 03:00:00 GMT  
 Problem with Debugger/IDE in VC++6 Pro, NEED HELP PLEASE

Quote:
> > Hi Scott,

> > Thanks for your replu, I'm not sure I understand you, there isn't a problem with my code

> That's incredible confidence. I strongly suspect that you are wrong
> and that there _is_ something wrong with your code. You may want
> to try running your code under BoundsChecker or Purify to try and
> track down the problem.

I know, and I still stand behind my words. Its not my code, I didn't change
anything at home ...I have a very strong feeling its the environment
either VC++ or my Win2K...

Well guess what I did today, zipped my home code took it to work
recreated the environment and debugged, no problem...so I know
its not my code. I did my checking before posting my message,
though I'm not an expert in assembly...

Peter



Fri, 02 May 2003 03:00:00 GMT  
 Problem with Debugger/IDE in VC++6 Pro, NEED HELP PLEASE

Quote:
> Well guess what I did today, zipped my home code took it to work
> recreated the environment and debugged, no problem...so I know
> its not my code. I did my checking before posting my message,

Your self confidence grows ever stronger. It's misplaced I'm afraid.

Did you check the output window for error messages?

Don't tell me - let me guess. It works fine on Win9x, and works
fine when not running under a de{*filter*}, but fails on NT/Win2K,
when running under the de{*filter*}. Based on your description
of the symptoms I can tell you almost exactly what is happening:

When you run an application under the de{*filter*}, NT and Win2K
do some extra error checking. They check for certain types of
memory corruption, and they check for illegal parameters to
some of the memory functions. If they detect a problem, they
trigger a 'user breakpoint'. But first they print a message to the
output window describing what problem was detected.

Just because the memory corruption isn't causing visible
problems at home doesn't mean that your code is correct.
Many very serious bugs don't show up reliably. The memory
corruption detection in NT/Win2K is designed to help
address this problem.

Check the output window. It will give you more information
about the problem. Type Alt+2 to open the output window.

I'll betcha 10 bucks it's a bug in your program.

Quote:

> > > Hi Scott,

> > > Thanks for your replu, I'm not sure I understand you, there isn't a problem with my code

> > That's incredible confidence. I strongly suspect that you are wrong
> > and that there _is_ something wrong with your code. You may want
> > to try running your code under BoundsChecker or Purify to try and
> > track down the problem.

> I know, and I still stand behind my words. Its not my code, I didn't change
> anything at home ...I have a very strong feeling its the environment
> either VC++ or my Win2K...

> Well guess what I did today, zipped my home code took it to work
> recreated the environment and debugged, no problem...so I know
> its not my code. I did my checking before posting my message,
> though I'm not an expert in assembly...

> Peter

--
.Bruce Dawson, Humongous Entertainment (we're hiring).
http://www.*-*-*.com/
Send job applications by e-mail, post technical questions
to the newsgroups please. Thanks.


Fri, 02 May 2003 03:00:00 GMT  
 Problem with Debugger/IDE in VC++6 Pro, NEED HELP PLEASE

Quote:

> > Well guess what I did today, zipped my home code took it to work
> > recreated the environment and debugged, no problem...so I know
> > its not my code. I did my checking before posting my message,

> Your self confidence grows ever stronger. It's misplaced I'm afraid.

I'm just going to ignore this...I think you are getting the wrong picture...

Quote:

> Did you check the output window for error messages?

I'm not sure if there are any. I'm in debug build, I run the de{*filter*},
I get that message I described previously and I'm currently looking at disassembly
window. I did take a look at the output window and here is the output:

Loaded 'F:\WINNT\System32\ntdll.dll', no matching symbolic information found.
Loaded symbols for 'F:\WINNT\system32\MFC42D.DLL'
Loaded symbols for 'F:\WINNT\system32\MSVCRTD.DLL'
Loaded 'F:\WINNT\system32\KERNEL32.DLL', no matching symbolic information found.
Loaded 'F:\WINNT\system32\GDI32.DLL', no matching symbolic information found.
Loaded 'F:\WINNT\system32\USER32.DLL', no matching symbolic information found.
Loaded 'F:\WINNT\system32\ADVAPI32.DLL', no matching symbolic information found.
Loaded 'F:\WINNT\system32\rpcrt4.dll', no matching symbolic information found.
Loaded 'F:\WINNT\system32\SHELL32.DLL', no matching symbolic information found.
Loaded 'F:\WINNT\system32\shlwapi.dll', no matching symbolic information found.
Loaded 'F:\WINNT\system32\comctl32.dll', no matching symbolic information found.
HEAP[XOOB.exe]: Heap block at 001344A8 modified at 001344DC past requested size of 2c   <------- Cound be the problem ?

Quote:

> Don't tell me - let me guess. It works fine on Win9x, and works
> fine when not running under a de{*filter*}, but fails on NT/Win2K,
> when running under the de{*filter*}. Based on your description
> of the symptoms I can tell you almost exactly what is happening:

Actually I'm not running Win9x and the de{*filter*} works fine in NT
which in this case I'm assuming you are talking about NT4,
like I said I have no problems at all on my NT4 box at work.
I no genius but I'm smart enough not do development under
Win9x if I don't really need to.

Quote:

> When you run an application under the de{*filter*}, NT and Win2K
> do some extra error checking. They check for certain types of
> memory corruption, and they check for illegal parameters to
> some of the memory functions. If they detect a problem, they
> trigger a 'user breakpoint'. But first they print a message to the
> output window describing what problem was detected.

I'm not using any memory functions, I am using MFC and
I know it does have some memory leaks perhaps in my
case I'm using some code that does the leak. I have simple SDI
app with a tree control and all I'm doing is managing some
C type structures that's all...

Quote:

> Just because the memory corruption isn't causing visible
> problems at home doesn't mean that your code is correct.
> Many very serious bugs don't show up reliably. The memory
> corruption detection in NT/Win2K is designed to help
> address this problem.

> Check the output window. It will give you more information
> about the problem. Type Alt+2 to open the output window.

> I'll betcha 10 bucks it's a bug in your program.

So what do you think based on the messages in my output window ?

Peter



Sat, 03 May 2003 12:30:29 GMT  
 Problem with Debugger/IDE in VC++6 Pro, NEED HELP PLEASE


Quote:
>> > Hi Scott,

>> > Thanks for your replu, I'm not sure I understand you, there isn't a problem with my code

>> That's incredible confidence. I strongly suspect that you are wrong
>> and that there _is_ something wrong with your code. You may want
>> to try running your code under BoundsChecker or Purify to try and
>> track down the problem.

>I know, and I still stand behind my words. Its not my code, I didn't change
>anything at home ...I have a very strong feeling its the environment
>either VC++ or my Win2K...

>Well guess what I did today, zipped my home code took it to work
>recreated the environment and debugged, no problem...so I know
>its not my code. I did my checking before posting my message,
>though I'm not an expert in assembly...

Use "depends.exe" to view the dll's your exe uses.  Check the versions
of all dll's both at work and at home.  Is there a difference anywhere
?

As for this lot:

Quote:
>NTDLL! 77f9eea9()    <-- Arrow Pointer
>NTDLL! 77fcd942()
>NTDLL! 77fb54c9()
>NTDLL! 77fb4732()
>NTDLL! 77fa6567()
>NTDLL! 77fcabc7()
>USER32! 77e1b38d()
>USER32! 77e1ad47()
>USER32! 77e16ce0()
>USER32! 77e27656()

Install the symbolic information from the NT cd and from the
service-pack cd (must match the correct sp as you have installed).
This will give you a better read-out from the stack.

My money is on a version mismatch of the MFC debug dll's or the
run-time dll's.

Jimbo



Sat, 03 May 2003 03:00:00 GMT  
 Problem with Debugger/IDE in VC++6 Pro, NEED HELP PLEASE
Thanks for your info Bruce I will look into it. I'm starting to suspect
that something is wrong/different with MFC libraries between
my work's NT4 (SP4) VC++6 Entr. (SP3) and my home Win2K
(SP1) VC++ 6 Pro (SP4)...I will take a look at the knowledge base
document...

Peter

PS: Yes the de{*filter*} message about "user breakpoint" confused
        the hell out of me...

Quote:

> Peter,

> I know my comment about misplaced confidence sounded a bit rude,
> but it was not meant to be rude - just a ruthlessly accurate
> assessment. I've seen the symptoms that you were describing many
> times and they have _always_ indicated a bug in the program. Plus,
> since it is impossible to ever ensure that code has no bugs in it, any
> statement that an unknown problem is not in your code is dubious.

> Anyway, on to the specifics:

> > HEAP[XOOB.exe]: Heap block at 001344A8 modified at 001344DC past requested size of 2c   <------- Cound be the
problem ?

> Yes, that indicates the problem. Your application requested memory and
> received a pointer to 0x2C (44 decimal) bytes at location 0x001344A8.
> Your application then modified memory at location 0x001344DC. That
> location is 0x34 (52 decimal) bytes beyond the start of the allocation.
> In other words, a stray write, either through the 0x001344A8 pointer
> or through some other pointer. Either way, unallocated memory was
> written to. Win2K detects that by, when running under the de{*filter*},
> padding allocations, initializing the pad area to special values, then
> checking them when the allocations are freed.

> So, it's definitely a bug, but the confusing thing is that the error
> message doesn't appear until long after the bug has happened. The
> bug is not detected until the memory is freed.

> I can't remember whether NT 4.0 has this feature. I thought it did, but
> I was probably mistaken.

> So, now you need to find out who is doing the stray write. Bounds
> Checker and Purify are good at tracking down such things, if you
> have access to them. Win2K also has some interesting memory
> allocation options that you can set on a per application basis. You
> can tell Win2K to put each allocation on its own MMU page. Then,
> stray writes will typically cause access violations at the time of the
> stray write, instead of being detected much later. For more
> information, check out this article:
> http://www.*-*-*.com/

> > I no genius but I'm smart enough not do development under
> > Win9x if I don't really need to.

> I agree that Win9x is best avoided, especially for developing.

> I hope this information helps. I know that these 'user breakpoints'
> confuse people the first time, especially if you don't typically have
> the output window open.



Sat, 03 May 2003 03:00:00 GMT  
 Problem with Debugger/IDE in VC++6 Pro, NEED HELP PLEASE

Quote:



> >> > Hi Scott,

> >> > Thanks for your replu, I'm not sure I understand you, there isn't a problem with my code

> >> That's incredible confidence. I strongly suspect that you are wrong
> >> and that there _is_ something wrong with your code. You may want
> >> to try running your code under BoundsChecker or Purify to try and
> >> track down the problem.

> >I know, and I still stand behind my words. Its not my code, I didn't change
> >anything at home ...I have a very strong feeling its the environment
> >either VC++ or my Win2K...

> >Well guess what I did today, zipped my home code took it to work
> >recreated the environment and debugged, no problem...so I know
> >its not my code. I did my checking before posting my message,
> >though I'm not an expert in assembly...

> Use "depends.exe" to view the dll's your exe uses.  Check the versions
> of all dll's both at work and at home.  Is there a difference anywhere
> ?

I will check it out...another example of "DLL HELL"... I suppose..

- Show quoted text -

Quote:

> As for this lot:

> >NTDLL! 77f9eea9()    <-- Arrow Pointer
> >NTDLL! 77fcd942()
> >NTDLL! 77fb54c9()
> >NTDLL! 77fb4732()
> >NTDLL! 77fa6567()
> >NTDLL! 77fcabc7()
> >USER32! 77e1b38d()
> >USER32! 77e1ad47()
> >USER32! 77e16ce0()
> >USER32! 77e27656()

> Install the symbolic information from the NT cd and from the
> service-pack cd (must match the correct sp as you have installed).
> This will give you a better read-out from the stack.

> My money is on a version mismatch of the MFC debug dll's or the
> run-time dll's.

> Jimbo
> --


Thanks Jim I will check the MFC debug Dlls versions I belive there
will be a difference since:

1) work - NT4  Ws (SP4)  and VC++ 6 Entr. (SP3)
2) home - Win2K Pro (SP1) and VC++6 Pro (Sp4)

Peter



Sat, 03 May 2003 03:00:00 GMT  
 Problem with Debugger/IDE in VC++6 Pro, NEED HELP PLEASE


Quote:

>> My money is on a version mismatch of the MFC debug dll's or the
>> run-time dll's.

>Thanks Jim I will check the MFC debug Dlls versions I belive there
>will be a difference since:

>1) work - NT4  Ws (SP4)  and VC++ 6 Entr. (SP3)
>2) home - Win2K Pro (SP1) and VC++6 Pro (Sp4)

It's not too important for NT4 -> NT5 (but may subtley be so :-) ) but
the 2 different versions of DevStudio, standard to pro and SP3 to SP4
would niggle in my mind more.  At work you've got the full-blown
dev-suite with older fixes, but at home you've got a cut-down version,
but with newer fixes :-)  The only way to go is to mirror the VC setup
on both machines which will leave you with only the OS
incompatabilities.

DLL Hell ?  Only for developers this one, but we should know what
we're doing :-)

Jimbo



Mon, 05 May 2003 03:00:00 GMT  
 Problem with Debugger/IDE in VC++6 Pro, NEED HELP PLEASE

Quote:
>> My money is on a version mismatch of the MFC debug dll's or the
>> run-time dll's.

Why? The evidence clearly indicates that some memory corruption is
occuring. Why do you think that an MFC dll mismatch is the cause
of that? It seems quite plausible that the memory corruption is
happening in both places, but only Win2K is helpful enough to detect
it. It _may_ be a DLL mismatch, but I haven't seen any evidence
to support that.

If a program that I write is corrupting memory, then my
automatic reaction is to assume that this is my fault. 99% of the time
I'm correct and it is my fault. Assuming that the problem is
somebody else's does not tend to lead to a solution.

BoundsChecker, Purify, or PageHeap let you track down the
memory corruption in a reliable and scientific way instead of
making vague guesses about DLL mismatches.

Quote:




> >> My money is on a version mismatch of the MFC debug dll's or the
> >> run-time dll's.

> >Thanks Jim I will check the MFC debug Dlls versions I belive there
> >will be a difference since:

> >1) work - NT4  Ws (SP4)  and VC++ 6 Entr. (SP3)
> >2) home - Win2K Pro (SP1) and VC++6 Pro (Sp4)

> It's not too important for NT4 -> NT5 (but may subtley be so :-) ) but
> the 2 different versions of DevStudio, standard to pro and SP3 to SP4
> would niggle in my mind more.  At work you've got the full-blown
> dev-suite with older fixes, but at home you've got a cut-down version,
> but with newer fixes :-)  The only way to go is to mirror the VC setup
> on both machines which will leave you with only the OS
> incompatabilities.

> DLL Hell ?  Only for developers this one, but we should know what
> we're doing :-)

> Jimbo
> --


--
.Bruce Dawson, Humongous Entertainment (we're hiring).
http://www.humongous.com/
Send job applications by e-mail, post technical questions
to the newsgroups please. Thanks.


Tue, 06 May 2003 03:00:00 GMT  
 
 [ 28 post ]  Go to page: [1] [2]

 Relevant Pages 

1. Need Help on debugger for VC Pro v6

2. I need vc ide macro help, trying to create a move to end of word macro

3. I need vc ide macro help, trying to create a move to end of word macro

4. New to VC, need help for debugger

5. C++ Builder Stack Overflow Error - Please help - Need to know how to overcome this Debugger Exception

6. PLEASE HELP: I AM NEW TO DEBUGGER (Turbo Debugger 3.0)

7. Debugger problem, please help

8. Access violations in IDE debugger, works fine outside of IDE

9. Need help with dialog .cpp source in VC 1.52 please

10. Need help on this programming problem ( PLEASE HELP!!!)

11. NEED HELP WITH PRITING AN ARRAY, PLEASE PLEASE HELP

12. January 2002 MSDN problem with VC++6 Pro

 

 
Powered by phpBB® Forum Software