Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

Succinct

[MSVC++] effects of set_new_handler and set_new_mode(1) in a client DLL on host code

This topic is 5764 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I''m writing a plug-in type DLL for Sonar (a music recording software package). I have no idea what the Sonar host-app''s _new_handler, _new_mode, and _seh_translator settings are, but I know that in most of my programming, I have them set up to behave in a fasion more similar to C++ - i.e. throwing exceptions when they encounter exceptional conditions. Will changing any of these parameters from a client DLL affect the settings of the host app? I''m not sure, and I''m not sure how to test the host''s behavior... Further, I''m pretty sure that most of my code will executed from a seperate thread, but I''m not sure that all of it will. This is important because I know that at least seh_translator is defined on a per-thread basis, though I''m not sure for the other functions. Thank you for your bandwidth! Succinct

Share this post


Link to post
Share on other sites
Advertisement
quote:
Original post by Succinct
Will changing any of these parameters from a client DLL affect the settings of the host app? I''m not sure, and I''m not sure how to test the host''s behavior...


check if it''s linked to crt dynamically, that is, if it has imports from msvcrt.dll or msvcr70.dll. you can use dumpbin tool or dependency viewer.

Share this post


Link to post
Share on other sites
Thank you, Niyaw... I didn''t expect anyone to reply...


well, dumpbin showed nothing of interest:

  
Microsoft (R) COFF Binary File Dumper Version 6.00.8447
Copyright (C) Microsoft Corp 1992-1998. All rights reserved.


Dump of file sonar.exe

File Type: EXECUTABLE IMAGE

Summary

3E000 .data
1000 .data1
BA000 .rdata
36B000 .rsrc
322000 .text
1000 .tls


though, depends.exe showed me that it does depend on msvcrt.dll directly once and indirectly through quite a few other .DLLs. I assume this means that if my DLL is executed, the thread executing my DLL will have it''s _set_new_mode, _set_new_handler, and set_seh_translator to all execute within the same address space as the thread loading my library in the host .DLL, thus changing the settings for the entire host app in that thread context. I don''t know how the app will respond to such behavior...

Is my call to _set_seh_translator going to force the host application to use my seh_translator? The only possibility I can see of it -not- doing so is the undocumented case of because it''s loaded from a .dll, it is not the case. Being that this is undocumented, though, I cannot be sure of the behavior untill I test it myself, and even then, cannot be sure of the behavior from build to build and os version to os version.

I''m planning on testing it tomorrow, to see, but that means I have to deliberatly crash the host app by, say, forcing a divide by zero or allocating too much memory inside of a host-allocated client object.

If anyone can give me previous experience or a link to somewhere who''s done it, that''d be the best! If not, well, it''s pretty vague and specialized anyway...

One possible source of action would be to define the .dll interface in a finite set of handle based functions, and have each function that operates on one of my handle-types setup my client state at the beginning of the function and restore it at the end of the function. This will not only hinder performance I''m sure, but unless all of the functions to change the parameters are put into a single class that cleans up on destruction, any function that returns mid-function or throws will not have those parameters reset...

Thank you for your bandwidth,
-- Succinct

Share this post


Link to post
Share on other sites
quote:
Original post by Succinct
well, dumpbin showed nothing of interest: <snip>


use /imports switch to get the imports listed.
quote:

I assume this means that if my DLL is executed, the thread executing my DLL will have it''s _set_new_mode, _set_new_handler, and set_seh_translator to all execute within the same address space as the thread loading my library in the host .DLL, thus changing the settings for the entire host app in that thread context.


exactly.
quote:

Is my call to _set_seh_translator going to force the host application to use my seh_translator?


yup.
quote:

The only possibility I can see of it -not- doing so is the undocumented case of because it''s loaded from a .dll, it is not the case.


i''m not sure what you mean by it, but what you can do is link to crt statically. then your dll will have its own private copy of all crt data structures and it shouldn''t conflict with the host exe. of course, there are two drawbacks:
- unnecessary duplication of crt code; and
- inability to share crt data, such as FILE handles, between exe and dll, and inability of one of them to allocate memory that will be freed by the other.
however, you may not need to do these things at all.
quote:

One possible source of action would be to define the .dll interface in a finite set of handle based functions, and have each function that operates on one of my handle-types setup my client state at the beginning of the function and restore it at the end of the function.


this sounds suspiciously similar to MFC''s AFX_MANAGE_STATE macro.

Share this post


Link to post
Share on other sites
phew!

Glad to see someone else on the same page here.

For the stuff my app will be doing, it will almost exclusively be buffer processing - host gives me an address and a size, I process the buffer, and tell it I''m done (return). No files will be shared, no memory will transfer ownership, and no other allocated resources should end up being used.

Linking statically w/ the CRT should work.

Thanks for the help, man!

-- Succinct

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!