|
Hi Ravi,
Thanks again for the help. I have now located the problem but haven't figured out how to fix it yet. The problem lies with password encrypted zip files. If the zip files that are extracted aren't password encrypted, they work fine on Win98. If they are, they spew the error. So far I don't know if this has to do with the zip library I'm using (I don't think so, as it is supposed to be compatible with Win98 - it is the one from http://www.artpol-software.com), or with the password encryption I'm using. I'm using cryptography.cpp and cryptography.h, which use the Windows CryptoAPI (got them from Planet Source Code), to encrypt the password and store it in an INI file. The program then reads the encrypted password, converts it and passes it to the Zip...
I doubt posting the code will help as it's very specific (relying on cryptography.cpp and .h and the zlip library from artpol software), but I'll post it just in case. The code I am using is really straight out of the example files (I do a GetPrivateProfileString for Password_str, the default being "NO_PASSWORD_DEFINED"):
//Open the Zip file:
CZipArchive zip;
zip.Open(ZipFile_str);
//If there is a password, decrypt and set it:
if(strcmp(Password_str,"NO_PASSWORD_DEFINED")!=0)
{
//DECRYPT PASSWORD FOR ZIP FILE:
char *sUnencrypted;
clsCryptography MyCrypt;
//Decrypt data:
MyCrypt.bDecryptData(Password_str, "zE76c78cae9opzz231fx" );
// Allocate enough memory to hold unencrypted value
sUnencrypted = new char[MyCrypt.lGetBufferLength() + 1];
// Store unencrypted value in variable
strcpy( sUnencrypted, MyCrypt.sGetBuffer() );
//Pass the decrypted password into the ZIP file:
zip.SetPassword(MyCrypt.sGetBuffer());
delete[] sUnencrypted;
}
Many thanks,
Keith
|
|
|
|
|
According to the documentation, memcpy does not guarantee the result if the source and destination overlap; on the other hand, memmove will graciously handle the case, by coping first the overlapping region.
Consider the following example :
char szTempCpy[] = "this is the most reliable test";
char szTempMov[] = "this is the most reliable test";
memcpy( szTempCpy + 5, szTempCpy, 25);
memmove( szTempMov + 5, szTempMov, 25);
printf("memcpy : %s\nmemmove : %s\n", szTempCpy, szTempMov);
Now, when this is compiled in release you will get the correct behavior : memcpy will trash the data ( the ouput is "this this this this ...") and memmove will get it right ( "this this is the most ...").
The surprise comes when you compile debug : both memcpy and memmove will yield the same result ( the correct one ) - "this this is the most ...". Does anybody have a good explanation for this ?
|
|
|
|
|
the memcpy function has this little bit at the front:
; Check for overlapping buffers:
; If (dst <= src) Or (dst >= src + Count) Then
; Do normal (Upwards) Copy
; Else
; Do Downwards Copy to avoid propagation
mov eax,ecx ;V - eax = byte count...
mov edx,ecx ;U - edx = byte count...
add eax,esi ;V - eax = point past source end
cmp edi,esi ;U - dst <= src ?
jbe short CopyUp ;V - yes, copy toward higher addresses
cmp edi,eax ;U - dst < (src + count) ?
jb CopyDown ;V - yes, copy toward lower addresses
-c
Image tools: ThumbNailer, Bobber, TIFFAssembler
|
|
|
|
|
This protection seems to be implemented only in debug version, and I personally think is a major pain because it lets some easy to catch bugs to creep unobserved. I would expect release and debug versions to be consistent, not to have a different functionality
|
|
|
|
|
the MSDN does say that you shouldn't use memcpy for overlapping buffers. so, i don't think you can argue that it should work at all in such a situation.
-c
Image tools: ThumbNailer, Bobber, TIFFAssembler
|
|
|
|
|
I perfectly agree - it is not supposed to work at all. I don’t understand why is working. Anyway, if you will take a look at the example in MSDN you'll see that the output is perfect ( compiled debug, I suppose ), even if the note says "MEMCPY.C: Illustrate overlapping copy: memmove, handles it correctly; memcpy does not"
|
|
|
|
|
There is an article here at code project that says you can print directly to a printer by using fopen("lptN", "w") and writing to the file (just like normal).
I really want to belive this because I have text and HP GL commands in a file that I need to send out to the printer.
I try to fopen("lpt1", "w"); but I get a null pointer back.
I did successfully map a printer to lpt1 (identical to his code except for the \\server\printer) (I don't remove it so I can heck via "net use")
I am in windows 98. Does anyone have any ideas why it's not working?
|
|
|
|
|
Try LPT: . I think (but am not sure) this is mapped to the default printer.
/ravi
Let's put "civil" back in "civilization"
http://www.ravib.com
ravib@ravib.com
|
|
|
|
|
Nope.
PRN doesn't work either.
|
|
|
|
|
Here's another kicker.. opening \\server\printer works, but LPTx doesn't!
|
|
|
|
|
LPT stuff designs a printer connected to the parallel port. I doubt this will work with a USB printer or a network printer.
|
|
|
|
|
I believe the LptN explicityly refers to the physical LPT port. If you have redirected this port then you cannot write to it. This explains why you are able to write data to the UNC name not the physical port name.
|
|
|
|
|
fopen ("lpt1:", "w")
Don't forget the colon.
Sonork 100.11743 Chicken Little
"You're obviously a superstar." - Christian Graus about me - 12 Feb '03
Within you lies the power for good - Use it!
|
|
|
|
|
Does any one know how to fix the drawing of the handle on a floating CToolBar.
Problem: When the handel is drawn only the raised portion is actualy painted the area surrounding it is not.
Trust in the code Luke. Yea right!
|
|
|
|
|
how to initialize menu by right mouse click?
|
|
|
|
|
TrackPopupMenu ( or something like that ... )
You need a menu resource.
Maximilien Lincourt
For success one must aquire one's self
|
|
|
|
|
I am new to Visual C++, and I added a class to a project, and now would like to remove it. I managed to delete the files from the file view of the project, but when I build, I still get "No Such File Error". Can some one tell me how to remove files from a project?
Thanks
Kevin Shaffer
Student of Computer Science
University of Kansas
kshaff03@msn.com
|
|
|
|
|
Check to see if any files in your project are doing a #include on your deleted files.
Phil Boyd
MCP
CPT, AR
You may be gone, but we will never forget your sacrifice.
"Proud to be an American..." Lee Greenwood
|
|
|
|
|
That was it! Thanks
Kevin Shaffer
Student of Computer Science
University of Kansas
kshaff03@msn.com
|
|
|
|
|
I assume you mean you deleted it from the work space and assuming you also remove any reference, if any, in the rest of your code. Then just press 'Rebuild All' because you need to rebuild the precomiled header(s). You will find that there may be many occasions when a minor change in code will generate unexpected errors that will disapear by simply pressing 'Rebuild All'.
Trust in the code Luke. Yea right!
|
|
|
|
|
Hi All !
Does anyone know the way to share one COM-port for a few applications ?
I know that OS gives only one handle for COM-port for all applications, but may be exist some sharing method ?
|
|
|
|
|
I do not know what you are trying to do?
Are you writing all the applications that needed to share the COM-port?
If so, then only open the port when you needed to use it and close it when done. This should allow any other application on your system to use it when you are not.
If you want to share it with other application out side of your control. Sorry, if they keep it open continuiously
then there is nothing you can do but close that application.
Trust in the code Luke. Yea right!
|
|
|
|
|
You make no sense.
Which of the XX ports sharing the port should control the hardware lines? Any? All?
What you might want is a proxy, one app to take commands from mulitple sources, queue them, and spit them out. When stuff comes in, who then gets it? the next person to call read, or all of them?
|
|
|
|
|
By nature the comm ports are asyncronous. "sharing" them is not feasible as it makes logical sence that only one program at a time would be reading / writing data via a comm port.
Simply open them when you have data you wish to read from or write to the port and close it as soon as you are done.
Some applications are arrogant enough to think that they have permenant control of hardware resources such as the comm ports. Palm "Hotsync" is one that comes to mind, opening the comm port and holding it open the entire time it runs. The solution to someone needing to share the comm port is to close these errant apps and only allow them control of the port when their device is read to communicate via the comm port.
I guess that last sentence really says it all. By nature you need to know when "your data" is coming down the async stream and read it. The rest of the time you care less what data is coming in. The same goes for outbound data.
On the other hand if you truly wish to "share" the data coming in via the comm port then write a single program that reads and records the data to a fifo file and use that file as input to the various applications that are all wanting to read the same data. You cannot share the port for output since that would mean a garbled data stream going out.
|
|
|
|
|
Hi!
I have a database project using MFC and ODBC. When we create a ODBC project, we obtain a CMyRecordView class derived from CRecordView. This class use a dialog template to represent data.
I want to use a CListCtrl to represent my data.
So in my class CMyRecordView.h I have declared
CListCtrl m_wndListCtrl;
In my CMyRecordView.cpp :
DDX_Control(pDX, IDC_LISTCTRL_VIEWDATA, m_wndListCtrl);
and :
void CDataBaseManagerView::OnInitialUpdate()
{
m_wndListCtrl.InsertColumn(0,_T("Item"),LVCFMT_LEFT,100);
m_wndListCtrl.InsertColumn(1, _T("Value"),LVCFMT_LEFT, 100);
m_wndListCtrl.InsertColumn(2, _T("Time"), LVCFMT_LEFT, 100);
m_pSet = &GetDocument()->m_DataBaseManagerSet;
CRecordView::OnInitialUpdate();
}
In my dialog, my control style is set to VS_REPORT
The problem is that I dont see my columns.
I see a grey bar, but I dont see any text and I dont see any line break.
thanks for helping...
Everything's beautiful if you look at it long enough...
|
|
|
|