|
As you said, there's no native TCP/IP support in MS-DOS. A number of companies sell their own implementations of a TCP/IP library for MS-DOS (both for 16-bit apps and for 32-bit MS-DOS extenders). Do a search for "IP stack MS-DOS" on the net to get some links. Some of the libraries (like for instance WATTCP) are free.
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
i want to simulate signal -- SIGALRM of ANSI C in to vc++
for that i m using settimer api but it not doing callback....plz help me out on this topic.......
code what i wrote is---->
#include <windows.h>
#include <stdio.h>
#include <conio.h>
UINT uResult;
VOID CALLBACK TimerAPCProc(
HWND hwnd, // handle to window for timer messages
UINT message, // WM_TIMER message
UINT idTimer, // timer identifier
DWORD dwTime) // current system time
{
printf("bharat");
getch();
}
int main(void)
{
uResult = SetTimer(0, // handle to main window
0, // timer identifier
10, // 10-second interval
(TIMERPROC) TimerAPCProc); // timer callback
if (uResult == 0)
{
printf("No timer is available.");
}
Sleep(20);
uResult=KillTimer(0,uResult);
if (uResult == 0)
{
printf("No timer is available.");
}
}
|
|
|
|
|
First of all, please next time tick on the "Display this message as-is (no HTML)" checkbox just below the edit area to make your code appear OK (otherwise <code'<'< code=""> characters mess with the HTML rendering.)
I'm afraid you cannot use <code>SetTimer for console programs. SetTimer needs a message processing pump in your thread to function properly, even if you don't specify any hWnd .
Al alternative approach goes through launching a separate thread that Sleep s the required amount of time and then invokes the callback function. It is likely that someone have wrote some code for that already, so maybe you should do a search on the net before start coding.
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
Technically, you can use SetTimer in a console application. I do it all the time. You just need a message pump.
Tim Smith
Descartes Systems Sciences, Inc.
|
|
|
|
|
Technically, you can use SetTimer in a console application.
Of course.
I do it all the time
Do you? I'm curious as to know what kind of console apps you write with such a weird architecture. Do you mean your main thread falls into a GetMessage loop? If so, why do you choose console instead of a WinMain based solution?
No irony intended (really). I'm actually curious to know the reasons for devising this kind or architecture.
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
Well, let me back track a little.
I have maybe used SetTimer once or twice in a console application. But, many times I have used SetTimer in a worker thread that doesn't have windows. Until recently, we didn't want to use waitable timers since they aren't supported under 95. Thus we just used the old SetTimer.
Tim Smith
Descartes Systems Sciences, Inc.
|
|
|
|
|
You tried the SetWaitableTimer api?
It doesn't need a message pump.
Cheers,
Joao Vaz
|
|
|
|
|
|
Is there a way to determine how many separate bitmaps there are within a .bmp-file (e.g. one used for a toolbar). I like to find out the width and hight of every bitmap.
Thanks in advance,
Aart
|
|
|
|
|
Usually in a bitmap like this, all o fthe sub-bitmaps are the same size, so you could simply find out the width and the height of the bitmap in the header of the bmp file, then divide the smaller of the width and the height into the larger number, and that will tell you how many images are in the entire file.
Then the dimensions of the sub-images will be the smaller number for one dimension, and the larger number divided by the number of images in the file.
|
|
|
|
|
Hi Gurus!
Couuld you write me please the address, where I can download the SDK?
-George
Das war kein Heldenstueck, Octavio!
|
|
|
|
|
|
I was compiling this app tonight in release mode...multithreaded, statically linked. os is xp using vis studio .net
I went to test it out on my 2k box and got a dll error referring to msvcr70d.dll, msvci70d.dll, and mcvcp70d.dll.
would the user 'need' to have these dll's installed(in which case it does work)? or is there another way around this?
Basically, I'm just looking to have one executable to hand out and not all the accompanying dll's. I was under the impression if i 'statically linked' it the exe would not be dependant on those. Why wouldn't i just use a 'dynamically linked' solution; keeping the exe size down even further and sending along the dll's anyway?
also, i do have the dll's on my xp system....I assume from when i installed vis studio and they're not on the 2k machine.
Any elaboration into my dilemma would be greatly..GREATLY appreciated.
thank you,
gus
|
|
|
|
|
Are you 100% sure you are statically linking your app? I mean, those DLLs look like C run-time library DLLs. I'd suggest you thoughoughly check your app is actually being statically linked. Also, if you have any other project without this problem you could check what its settings are and try to find the differences.
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
You didn't test with the release version, but the debug version. The trailing d in the DLL names indicates they're the debug versions.
--Mike--
"There are only a limited number of jobs where they will ask to see the sausage. Most of them are in movies."
-- Christian Graus, 2/11/2002
My really out-of-date homepage
Sonork - 100.10414 AcidHelm
Big fan of Alyson Hannigan.
|
|
|
|
|
thanks for the tip. I tried creating a new project config (because the one i was using was imported from vis studio 6) and then change to 'statically link'. compiled, ran it and the same thing. below is the config settings if that helps.
Name="Release|Win32"
OutputDirectory="Release"
IntermediateDirectory="Release"
ConfigurationType="1"
UseOfMFC="1"
CharacterSet="2">
Name="VCCLCompilerTool"
Optimization="2"
InlineFunctionExpansion="1"
OmitFramePointers="TRUE"
PreprocessorDefinitions="WIN32;_WINDOWS;NDEBUG"
StringPooling="TRUE"
MinimalRebuild="FALSE"
RuntimeLibrary="0"
EnableFunctionLevelLinking="TRUE"
TreatWChar_tAsBuiltInType="TRUE"
UsePrecompiledHeader="3"
WarningLevel="3"
Detect64BitPortabilityProblems="TRUE"
DebugInformationFormat="3"/>
Name="VCLinkerTool"
AdditionalDependencies="id3lib.lib"
LinkIncremental="1"
IgnoreDefaultLibraryNames=""
GenerateDebugInformation="TRUE"
SubSystem="2"
OptimizeReferences="2"
EnableCOMDATFolding="2"
TargetMachine="1"/>
Name="VCMIDLTool"
PreprocessorDefinitions="NDEBUG"
MkTypLibCompatible="FALSE"
Is there one or more specific settings i should check to make sure it's statically linked? I'm using mfc and have that setting statically linked. I'm not sure of what others i would have to check. any ideas?
thanks again,
Eric
|
|
|
|
|
Mike,
I wanted to thank you for your help and 'tip'. I had an inkling that the trailing 'd' was a debug version but i couldnt understand why. what was really valuable was one of your faq articles....mentioning 'depends'. i loaded my exe in and none of the requested dll's were mentioned... however...there's a dll that i link to that DOES. turns out that i compiled it in debug mode. anyhow, i switched it over to release and reran my app. i still get the dll warning but this time they are not the debug versions(no trailing 'd'). Is there a way not to rely on those? i have the settings in the dll project to statically link as well.
if i compile the dll on a nt4 box they now will depend on older versions of the dll's. this method works just fine since most will already have them.
Eric
|
|
|
|
|
C:\Windows\Desktop\Project2\Project.cpp(759) : warning C4101: 'exception' : unreferenced local variable
|
|
|
|
|
You may safely ignore the warning.
Nish
Nish was here, now Nish has gone;
He left his soul, to turn you on;
Those who knew Nish, knew him well;
Those who didn't, can go to hell.
I like to on the Code Project
Sonork ID 100.9786 voidmain
www.busterboy.org
|
|
|
|
|
you defined a variable called "exception" on line 759 of project.cpp. You never bothered using it.
Sorry to dissapoint you all with my lack of a witty or poignant signature.
|
|
|
|
|
I would like to write a function in C++ and compile that into a .dll that I can access within Visual Basic. The purpose behind this is a company restriction and I feel the process can be handled most efficiently in the C++ environment. Does anyone know what I would need to do to compile it as such.
Here would be an example, but not my particular function:
int SumValue(int a, int b)
{
return a + b;
}
Thanks in advance
Nick Parker
|
|
|
|
|
COM is really the only way you can do this. I'm not much of a VB expert, but to get a function pointer in a DLL requires pointer support, which VB doesn't have. Therefore, you're going to need to create a C++ COM object with a method called SumValue. You should then be able to use this in VB.
You should be able to find plenty of articles about how to create a simple COM object on this site.
------------------------
Derek Waters
derek@lj-oz.com
|
|
|
|
|
I've created what I believe should be the method to do this:
1. Created a Win32 Dynamic Linked Library
a. Choose a simple .dll project
2. Wrote the function inside the header file.
3. Compiled the .dll ok and exited VC++
Launched VB
1. Added a module
2. Included the following code for the module
Declare Function SumValue Lib "sum.dll" (ByVal a As Integer) As Integer
3. Put a button on a form where I try to call the function SumValue
4. Get an error:
Run-time error '453' Can't find DLL entry point SumValue in sum.dll
Does anyone have a clue?
Thanks again
Nick Parker
|
|
|
|
|
I believe VB supports __stdcall functions from DLLs (like nearly the entire Win32 API). Try adding these lines to your function :
__declspec(dllexport) __stdcall int SumValue(int a, int b)
For my code I have a DllExport macro. If I were you I would probably make a macro to handle all of the above.
My jokes page
|
|
|
|
|
The function that you just wrote should be written like this to export it from the DLL.
__declspec(dllexport) __stdcall int SumValue(int a, int b)
{
return a + b;
}
dllexport exports it from your dll, and __stdcall is the calling convention that VB accepts. _cdecl is the default calling convention therefore if you just simply exported your function from the DLL and used it in VB, you program would probably crash.
In you VB program, at the top of the file that you would like to call this DLL, you will need to make this declaration.
Declare Function SumValue& Lib "yourdll" (ByVal a as Integer, ByVal b as Integer)
After this you should be able to use your function in VB.
|
|
|
|