|
vikas amin wrote: i need to make my code secure so
you dont code a DLL with binary directly. its also done with the same readable C++ code, so if somebody is able to see your MFC code, they'll also be able to see what's in your DLL right? if u consider hiding the DLL, y not hide the MFC application itself?? go for a DLL if u think your application'd need changes in future. or if u wanna use the process(dll) in multiple applications. (sharing the same code)
He is like a one-legged man in a bum kicking competition. -Novjot Sidhu
--[v]--
|
|
|
|
|
try Dll/Exe encrypter like ARMADILLO[^]
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
cheers,
Alok Gupta
VC Forum Q&A :- I/ IV
|
|
|
|
|
hi
I want to open the DLL files and see the code in them.
are there any tools for that?if so ,plz post the URL's.
thanx in advance
|
|
|
|
|
vamshin wrote: I want to open the DLL files and see the code in them.
No Such Thing Exist In world Today, From which you can reterive the code that already converted inro the machine langauge..
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
cheers,
Alok Gupta
VC Forum Q&A :- I/ IV
|
|
|
|
|
hi vamshin
what exactli do you like to see? "..and see the code in them" - there is no tool to produce 'souce code'.
karo
|
|
|
|
|
hi
i just wanted to know how can we know what functions are present in dll?
eg:i get a DLL created by another developer and i want to know the functions in that DLL.
Is type libraries(i.e tli and .tlh files) the answer???
plz throw some light on this issue
|
|
|
|
|
if the author of the DLL allow you to use its functions, he might have provided an header file as interface for you to know the functions synopsis you can use.
if not, whatever you will try is pure hack and certainly forbidden !
TOXCCT >>> GEII power
[toxcct][VisualCalc]
|
|
|
|
|
vamshin wrote: i just wanted to know how can we know what functions are present in dll?
Click start navigate to your Visual Studio entry in programs, select tools sub menu. In the tools sub menu you will find a program called Dependency viewer. Open the DLL with Dependency viewer it will give a list of all exported function names but not the arguments nor the returns. That’s up to you to figure out.
DEBUGGING : Removing the needles from the haystack.
|
|
|
|
|
If want to see the code of a compiled dll
then there is no real software availabel for that,
Some people do that it is a comples topic "Reverse Engg".
Vikas Amin
Embin Technology
Bombay
vikas.amin@embin.com
|
|
|
|
|
But using Reverse Engg.. present you the exact code
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
cheers,
Alok Gupta
VC Forum Q&A :- I/ IV
|
|
|
|
|
Hi,
I need to get the size of many (can be over 5000) files very fast. What would be the fastest way to do this? Also, durring the runtime of the application, it will be getting file sizes every second or so.
As far as I know, I can use GetFileSize or I can fseek() to the end of a file.
Thanks for the help! I'm bonkrd 
|
|
|
|
|
Doesn't really matter because the most expensive part is opening the file...
|
|
|
|
|
The file are the file in the Temporary Internet Files for the current user (\Documents and Settings\%USER%\Local Settings\Temporary Internet Files) folder. They are actually traversed with the Win32 Cache functions, but they don't give the correct file size (or just most of the time they leave the file size field of the file info structure to 0)
Since these are cached files, isn't their information cached somewhere also?
-- Andrei B (andreib.com/blog)
|
|
|
|
|
If you wan't the file size without opening the files (and I'm sure that's what you want) use the stat() or _stat() function.
stat() fills a stat struct and one of the members in that struct is the file size.
-- modified at 1:27 Tuesday 25th October, 2005
|
|
|
|
|
try to use CFileFind.
karo
|
|
|
|
|
andreizilla wrote: Also, durring the runtime of the application, it will be getting file sizes every second or so.
Why poll for something that may not exist (as frequently as one second)? Wouldn't it make more sense to let the OS tell you when the size of a file has changed?
"Take only what you need and leave the land as you found it." - Native American Proverb
|
|
|
|
|
Use FindFirstFile,FindNextFile and FindFileClose method, it return WIN32_FIND_DATA structure which DWORD nFileSizeHigh, DWORD nFileSizeLow member contain size of file.
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
cheers,
Alok Gupta
VC Forum Q&A :- I/ IV
|
|
|
|
|
hi! I'm a college student but on spare time like programming, I've been programming since I was ten, and this summer I'm getting my hands on a big C++ programming project. I'm currently on the "planning stage" and need help on the following:
First a few things you should know in order to help:
---------------------------------------------------
-Most of the coding is to be done on a 486dx2 8MB RAM 800MB HDD notebook, which is able to run W95 and DOS. Graphic mode works. I haven't tried Linux, but I don't think it would be practical, as I need as much HDD I can get for project sample data.
-My main goal is efficiency meaning speed (and results, though not relevant here) and compatibility with at least every Windows-DOS PC (allowing 640x480x256) and if possible Linux.
-This program will NOT use MFC, but needs to be able to init graphic mode at 640x480x256. I want specifically this as it looks pretty standard for compatibility with older PCs.
My problems:
------------
#1:
I was thinking of using pure ASM code to "init graph", "put/get pixel", etc, but i've been told that not all OS's will allow this (at least not all will allow me to write directly to video memory).
What should I do about this? Should I use some "graphics.h" or such?
#2:
I'll be doing heavy HDD I/O as the main task in this program will be file data analysing. I've read I should open files in binary mode as it is supposed to be the faster way to perform reading and writing. Is this true? What would be the most efficient way?
#3:
I need a very light and very specific Window-GUI (by specific I mean I won't need many controls and they will need to be adapted to the program's needs), so I was thinking of making one of my own. Taking out the "complexity" issue which is being taking care of, the real doubt here is: Will it truly be more efficient given I would use ASM for graphics routines, mouse routines and perhaps also keyboard routines? I point to that perhaps any other GUI already out there uses some other sophisticated techniques which would make them faster anyway... I should add that I'm not thinking of moveable/resizable windows, as it's more about n-criteria sorting flexgrids and checkable filelistboxes...
#4:
Some libraries already made objects from my project are currently working on VC++. Now, as you know, VC++ won't fit my 486  , I've thought about "CommandLineTools.exe" (8,5MB) from borland but it seems to lack of some really important libraries such as "conio.h"!?!? (goodbye getch, kbhit  ) So what I'm asking is: Which C++ distribution will fit best my needs, given all you've read so far? I've really enjoyed BCC55 (CommandLineTools.exe), is there any way I could use it? Perhaps extending the amount of libraries? What about GCC (the DOS version)? GCC should be the most compatible...
#5:
What are the main incompatibilities I should be aware of between XP, Dos 16bit and Linux? And, what key things won't be running on my 486?
#6:
As the visual interface will be graphic mode, I'll need fonts for displaying text, and MANY text will be displayed. I was thinking of making my own "font printf/cout" routines based on ASM putpixel, mostly because I don't need more than 3 different sizes nor more than 2-3 different fonts. Is this idea viable, once again taking out the complexity issue? Are there any font displaying libraries both light and simple to use out there?
#7:
While secondary to the main functionalities of the program, I will need to show BMPs, play WAVs, timing events and implementing sprites/masks. I've read there are many packages labeled as "Game Libraries" which do all this stuff, but all the ones I've found offer too many extra features which make the package too big and complex. Does someone know of a specific package which both handle my required features and is light in size/complexity? Will it work on my 486??
THX A LOT IN ADVANCE!! 
Mariano Lopez-Gappa (20) from Argentina
|
|
|
|
|
hi,
I'd written a program about 3 years ago whose requirements were very similar to urs. Since then I've never programmed in any other language other than VC. Even then, though i've forgotten a lot of things, lemme answer ur queries:
1. The problem with "ALL" OS is that most of them run in protected memory mode, hence they wud not allow u to directly write to memory. But there are ways, and prob'ly they are OS specific.
2. yeah, binary file read/write is almost always faster.
3. u may write ur own library. For 640x480x256, u might be thinking of using SVGA, though I found the SVGA a bit slower - using banking and all those stuff. I am pretty sure old monitors wont support SVGA.
4. Never been into those thins
5. As long as u stick to C++, there wont be any incompatibilities, but when jumping to asm, man - there are almost always incompatibilities.
6. For displaying fonts really fast, I'd preffered my own bitmapped fonts rather than the font libraries.
7. Showing BMP's and playing WAV's are pretty easy tasks, u can google for the algos and demo codes.
Hope this wud help u.
"Do first things first, and second things not at all."
— Peter Drucker.
|
|
|
|
|
Mariano Lopez-Gappa wrote: I was thinking of using pure ASM code to "init graph", "put/get pixel", etc, but i've been told that not all OS's will allow this (at least not all will allow me to write directly to video memory).
I don't see how you can target linux as well. IMO you should use DirectX for the fastest possible video. I don't think that asm is a good move, from a maintainability standpoint as much as anything, but I also believe that DX handles differences between video cards for you - you don't want to do that in asm.
Even creating a DIBSection will give you direct memory access to bitmap bits, although running in 256 colour mode means you're using a palette, which is always more messy than 16 bit or higher.
Mariano Lopez-Gappa wrote: read I should open files in binary mode as it is supposed to be the faster way to perform reading and writing.
That's possible, are you reading binary data, or text. You should use the class that's optimised for the sort of data you want to read. Worry about speed as it becomes an issue, and do your own tests to see what works best.
Mariano Lopez-Gappa wrote: Will it truly be more efficient given I would use ASM for graphics routines, mouse routines and perhaps also keyboard routines?
No. Using Win32 is as close to the machine as you need to get.
Mariano Lopez-Gappa wrote: Which C++ distribution will fit best my needs, given all you've read so far?
The command line compiler that comes with VC.
Mariano Lopez-Gappa wrote: What are the main incompatibilities I should be aware of between XP, Dos 16bit and Linux?
DOS means writing a text only program, or doing the graphics by hand. Linux will have it's own libraries for graphics. I don't see you targetting all three, without an abstraction that allows you to write three presentation layers.
Mariano Lopez-Gappa wrote: While secondary to the main functionalities of the program, I will need to show BMPs, play WAVs, timing events and implementing sprites/masks
Windows will let you show BMPs, play WAVs and run a timer.
Christian Graus - Microsoft MVP - C++
|
|
|
|
|
I think Borland Turbo C++ 3 should get the job done, but you will stay in 16-bit, which means a maximum of 640KB of RAM, out of which you will probably get 500KB. That is the main bottleneck.
1- You can use the SVGA modes. For 640x480x8, the mode is 0x101. There are lots of resources on the net for any graphics modes. Most PCs 486 dx2 will allow that mode (0x101). It actually depends on the Graphics Card RAM. You should have at least 1MB. However, any modern OS will not allow you to use these display modes. You may not use the graphics.h which comes with Turbo C.
2- Binary is faster.
3- About the GUI, you won't get anything. You will not even get basic I/O routines like cout, printf etc, or any GUI stuff like textout, outtextxy either. You will need to do them yourself. ASM may be used, but needed only for mouse-support, and to change the pallete (8-bit modes need to use palletes for bmps). If you are thinking about grids and listboxes, then it is a lot of work. I created such a library some years ago, it had editboxes, vector fonts, radio buttons, checkboxes, command buttons, keyboard, mouse support. It was hard work. And you will need to display the mouse cursor yourself also.
4- I have never used Linux, so I can't comment, but Borland Turbo C++ 3 or 3.1 should do. It has conio.h for getch, kbhit etc.
5- The 16-bit program will run well on a 486. But it may or may not run on Win2000, XP.
6- See (3) above. You might find such a library on the net.
7- For BMPs and Wavs, it is very cool for DOS programs to display pics and use the sound card. The bmp algorithm is easy to find on the net, but there is the limit of ram you can use. About wav files, find documentation for the sound card you are using, like Sound Blaster; Their docs are easy to find.
Hope that helps a little.
this is this.
|
|
|
|
|
First of all thx for your reply and thx to the other 2 guys replies. All of you helped a lot.
New questions have arised due to replies:
#1: My knowledge of technical differences between 16-32-64 bits is little or none...but I'm definitely gonna need more than 640K lol. There's gotta be a way to bypass the 640K limit! I thought mallocating on C and "New-ing" on Pascal allowed use of extended memory...
Well, if it just can't be done, I can work it out by not exceeding the limit while I use the 486...resigning compatibility with it, it's ok, it wasn't that big deal...nor was Linux compatibility.
It seems I'm gonna need a 32-bit compiler (though I don't really know much what it means), perhaps this is what "BBC32" meaning was (32 bit). What compiler should I use given the new circumstances? Will it still run on the 486?
#2: The graphic issue seems problematic, seems I'll have to make a first version working on the 486 and then the release one. So, given the first one is ok, what would be the better choice for graphic mode compatibility between W98-Me-NT-2000-XP? I should add that there's no way Ima use MFC nor DirectX.
Thx in advance!!
Mariano Lopez-Gappa
|
|
|
|
|
i use thread to animate an opengl object on a dialog box, it use "for" to loop and make a animate,
if not using thread, i use UpdateData(FALSE) and is see animation is moving,
BUT if i use thread i did see the movement, it see if i press button and other activity, any body help me ... plz...
|
|
|
|
|
Please state the question more clearly, possibly post some code.
John
|
|
|
|
|
try to use 'windows messages' to interact with dialogs. a good idea is to use WM_TIMER / SetTimer ...
karo
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
