|
i get blue screen on my system many time in a day no time limit
or my ram and harddrive is working well on another system wats the problame is there.
Give me good suggestion
|
|
|
|
|
AnupOmi wrote: Give me good suggestion
Check the information on the screen and look for clues as to what is wrong. I don't think we have any psychics here.
|
|
|
|
|
Richard MacCutchan wrote: I don't think we have any psychics here.
I think we do. The odds are extremely low there wouldn't be any amongst 6,464,695 members. However they may not be reading the question, or not be good enough and operate without a tiny bit of hard information.
Luc Pattyn
Have a look at my entry for the lean-and-mean competition; please provide comments, feedback, discussion, and don’t forget to vote for it! Thank you.
Local announcement (Antwerp region): Lange Wapper? Neen!
|
|
|
|
|
If they are psychic then they shouldn't need to read the question; they will just know 
|
|
|
|
|
I have a legacy app using VC 6 MFC and Codejjock 9.8 (not really relevant I don't think)
The program is broken into several pieces that communicate with each other via COM.
I am attempting to add USB support to a custom board. I have written a simple console test program that Uses WinUsb_WritePipe, Read Pipe. All is fine. When I incorporate the headers and calls into my legacy app I can;t get it to link. I either get duplicate symbol defined _WINUSB_TEST or unable to find uuid.lib, or a few others depending the order of the includes.
I should note I am statically linking MFC, building a debug build, and the wrapper USB class is usigng overlapped IO and is Multi Threaded (a seperate thread handles the IO with Thread Safe Queues buffering the data.
My gut tells me this is an incompatability with the libraries. Microsoft stopped supporting the SDK for VS6 in 2003. The DDK is 6001.1802.
I see a couple of options... Seperate the WinUsb code into a dll and hope the lib generated will link in with the main program.
Recompile everything using VS2008. I have been avoiding this for 2 reasons.
1. I have experimented with VS.net, 2003, 2005 and MFC support seemed to get worse as did the GUI's.
2. The real reason. THe programs combined have nearly 500KLocs of code. There are a lot of CStrings and the scope of x in for(int x=0; x < y; x++) statetents. All of which are problematic with the new compilers.
Any suggestions or help where I may be missing the boat would be greatly appreciated
|
|
|
|
|
Some suggestions if you decide to build it all in VS2008.....
The VS2008 CString class has a few quirks that were not there in VC6. The new MFC CString class is a lot more strict about index parameters going into functions like Mid, Left, Right, etc. What I ended up doing is derive my own subclass from CString and implement my own Left, Right, Mid, etc. handlers where my handlers would validate the index parameter(s) before calling the base class CString functions. I also did a little compiler gymnastics in redefining CString to CMyCString so as to not need to change every reference to CString in my project.
As for the for scope problem, there is a compiler switch that overrides the for scope compliance rule. Use the /Zc:forScope- compiler switch to turn off the for scope checking.
Out of curiosity, why are you statically linking MFC in a debug build?
|
|
|
|
|
I statically link the MFC DLL in release mode because I have found it makes deployment more robust. This program started with VS 1.52 if you can believe that, and has morphed and been factored, etc. Major Requirements creep. Over the years the differences in mfc dlls that were on win 95, 98, 98se, etc caused support issues. I am not really sure why I an doing it in the debug version to be honest other than for consistency. I have tried it both ways and it doesn't seem to make a difference.
Is there a reason not to statically link the MFC DLL in debug mode?
Back to the original question, I am thinking that using a dynamically linked (loaded) dll might get around the issue? Your thoughts?
|
|
|
|
|
Hi, my computer is running out of CMOS battery while its first use around 4 years. Then I bough the new battery around 4 month ago. Last week when i turn on my computer, i found that the date and time is not set. I think the battery is running out so I purchase the new battery. But after I replace to the new battery and set the date and time after I turn off and turn on again its still ask me to set the date again.
So I think this is not relate to battery. Could anyone let me know what is the cause of the problem that cause my computer to prompt for date and time setting everytime that I start up my desktop computer?
Thank in advance!!!
|
|
|
|
|
|
Shouldn't that read "bad mother" 
|
|
|
|
|
It could even have been "bad baby-mama". 
|
|
|
|
|
Are there any solution to fix it?
|
|
|
|
|
|
hi..
my cd drive is not working.Problem is that when a cd is inserted then no drive or icon of CD is shown.It is sudden problem in my system.One thing I want to add that when i start my system then a message is here that "Insert or rebbot your machine".
plz help me.....
thanks in adv.
|
|
|
|
|
jainiraj wrote: "Insert or rebbot your machine".
Can you remember the exact wording of the message as this does not really make sense? Can you access the CD through Windows Explorer, or access its properties through Device Manager?
|
|
|
|
|
thanks in adv.
Connecting to a wireless router which is not connected to any pc it directly connected to the outer unit which is getting signal , does this router would have any ip address if yes then how can i get /ping
well i tired ipconfig and stats are
dhcp enabled : Yes
autoconfig. Enables : Yes
IP Address : 192.168.0.6
and it has DHCP Address and DNS Address but this is my pc config. how can i get to know abt the ip address of router
Best Of Regards,
SOFTDEV
Sad like books with torn pages, sad like unfinished stories ...
|
|
|
|
|
The IP addresses listed under DHCP/DNS should be the addresses of the router. Assuming you are on Windows you can find this by viewing the properties of the wireless network connection for your system.
|
|
|
|
|
it worked thanks
Best Of Regards,
SOFTDEV
Sad like books with torn pages, sad like unfinished stories ...
|
|
|
|
|
Ok I googled the basics. Don't worry.
But still I'm not getting it. That's the problem. Please see if I'm getting it right.
First let me explain a situation without Device Driver:
ANY device that wants to be controlled through PC has a firmware written on top of it(On the device side itself). The devices gives us the option to control through PORTS. like serial/USB. We can control these devices by knowing the f/w spec. If we know the firmware spec, we can send direct commands through a port application and communicate with device. For example, I create a RS232 application and ask the printer to do any job I want assuming I know it's firmware spec. Here no drivers are needed.
With Driver:
When do we need a driver? If we want any application to talk to the device. Right? So we get the firmware spec and implement all I/O in a common driver dll and we keep this port I/O implementation functions into the driver and the OS maps the application calls through this driver right? How does this work? Can I write my own device driver to control the mouse? Can you explain/give link to know the sequence? Please Don't give examples with driver frameworks. I want to know the underlying basics. Thanks in advance.
----------------------------
286? WOWW!
|
|
|
|
|
without a specific driver your app might be able to interact with a peripheral, provided the peripheral uses a hardware interface that is supported by some general-purpose driver (e.g. for serial ports), and you implement all the peripheral-specific stuff yourself inside your app. That may solve the problem for one app using a (simple) peripheral one at a time.
with a driver you can use peripherals that could be shared (e.g. your LAN) and where incoming data gets to the interested party, you can apply protocols that need to be implemented only once (e.g. TCP/IP), and you can easily isolate your apps' problems from the drivers' problems. Would you like to have each and every app on your system to fiddle with the sectors of your disk?
|
|
|
|
|
Thanks for your reply.
Luc Pattyn wrote: without a specific driver your app might be able to interact with a peripheral, provided the peripheral uses a hardware interface that is supported by some general-purpose driver (e.g. for serial ports),
So if we write to a port using CreateFile, will that be using Serial-Driver? The serial driver gets loaded when you connect some device in the port or it's running always?
Also, does all hardware have the firmware on top for driver communication? Can any device without f/w be controlled by drivers alone?
Let me get little more simpler. Assume I have motor running in a device. Now I need to write a driver that handles the RMP of it. I want to read/ control the RPM.. What are the sequence required? Lot more to ask actually. I will ask.
----------------------------
286? WOWW!
|
|
|
|
|
_8086 wrote: So if we write to a port using CreateFile, will that be using Serial-Driver?
yes. a serial driver, there could be more than one e.g. one for the standard serial ports based on 16550 device, one for a specific USB-to-serial cable, etc. And there could even be more than one stacked on top of each other.
if by "device without firmware" you mean a dumb peripheral needing all its control from PC, that could be a bad idea; there was a time floppy drives had no intelligence, and interrupted the CPU for every byte transferred, that is once every 6 microseconds. You may remember Win98 with floppy activity didn't do anything else while a transfer was going on.
IMO peripherals need sufficient intelligence so they can left alone for 1 millisecond or more; so don't consider a PC driving a stepper motor; use a microcontroller for that.
Last advice: read some books and some articles on the subject.
|
|
|
|
|
thanks so much for this information. things are more clear to me now.
|
|
|
|
|
Often, in general, when people talk about a "device driver", that's low-level code that writes and read directly with the hardware. It uses absolute addresses. In general, user code can't write/read absolute hardware locations.
You would need a drive if you have custom hardware in your PC. That means if you make a PCI card with custom hardware, then a device driver needs to be written so that application-level programs can have access to the hardware. Think of it as a "delegate". 
The above is the "simple answer".
But, wait, there's more!
For something that goes on the USB or network, that gets more involved. There are many software/firmware/hardware levels in a Network/USB/Firewire transaction.
So, we can quickly get into "terminology hell/confusion" when we start talking about "drivers". 
I can argue what goes where in an application that uses TCP/IP over Ethernet. I can argue what goes where and why from the upper most GUI layer way down in the the core switching hub software. That's because of what I did in grad school and spent many many years in Networking.
But, with USB/Firewire, the distinction between hardware/firmware/software is always changing. Yes, it is similar in the Networking world. But, for me, words like "Brouter" (bridge/router) don't scare me, since I was designing Brouters in the 90's.
However, USB and Firewire are both very complicated! They are just as complicated as the TCP/IP flow. Maybe even more so since USB/Firewire now support so many different modes and hubs.
My point is that writing a "driver" for a new custom USB device is not the same as writing a driver for a new video card. Yes, they are both called "drivers". But, the "driver" that is written for a new USB device will be calling a lower level driver that talks directly to the USB chip/hardware. I hope that last sentence makes sense. Again, it's due to the different layers involved in a Network transaction. It may help to think of them as a "Layer 3 driver", "Layer 4 driver", etc.
So, a "driver" for a new USB device can easily be written in C# without the need to know any hardware details. Or, by knowing only a few higher level hardware details/limitations - like how fast the new device can take/send data if you don't want to overrun a buffer.
Since I do embedded CPUs and FPGAs, I often write low level drivers that directly control the hardware. It often takes a very good understanding of hardware and of the particular hardware.
On the other hand, I would be clueless on how to write a "USB driver" for a new custom USB device. There's a ton of stuff to learn and to understand. There's also the important interactions with the OS. I know of a number of USB devices that "hang the port" if they are disconnected without proper shutdown. I have a programmer for an embedded CPU that will blue screen my PC if I accidentally disconnect the USB during a chip program. That's a good case of someone that did a hack job writing the "USB driver" for that chip programmer.
Writing drivers are like that. Many people can write hack drivers. However, only a few people are very good at writing low level drivers. I know that Cypress is infamous for their horrible low-level drivers in their PSoC embedded CPU. They often have minimal or no error handling.
I like it because it's close to the hardware. Many people don't since it can be very hard to debug low-level drivers.
Hope the above helps, and doesn't confuse you more.
It may help to re-read it a few times. I tried to cover a lot of stuff in a little space.
______________
Joe
modified on Tuesday, September 8, 2009 3:00 AM
|
|
|
|
|
You've got some excellent answers here already, but let me add another that might help a bit.
Back in the good old days when we didn't have to deal with Windows I did a lot of programming devices; specifically, measuring devices to test military hardware. There were no standards then, not as we know them today. The operating system was customized for every machine model, and already "knew" how to send bits over a serial link or HPIB bus. But the languages used had constructs like READ_VOLTS(DC, 100, AVG, 10) to return the measured DC volts on a line, up to 100 Vdc, averaged over a period of 10 milliseconds.
But every oscilloscope, DMM, millivoltmeter, etc, recognized a different set of commands, unique to each manufacturer, and often each model. Usually these were in the form of text strings, and often the device listened for commands on a different physical address than the one used for data. For each device, we had to write a subprogram to translate what the operating system sent into a form the device could recognize. Today we'd call that subprogram a driver, and its job remains the same in the modern world.
If you were to design a new programmable device, a toaster perhaps, it would have built in commands that Windows knows nothing about. You might have a syntax containing something like:
ATDDSSSSHHMM#
where AT = Attention (new command setting follows)
DD = Darkness (1 - FF)
SSSS = Active slots (0001 - 1111)
HHMM = Start time (HH, hours; MM, minutes)
# = execute command
Your Toaster application program - the software your user runs to make toast - might output a command like:
Toast (Medium, 2, 5:30AM)
You would need to provide a driver to convert Medium to 80, 2 to 0011, and 5:30AM to 0530, then string them together into a command the toaster recognizes: AT8000110530#. On installation, your driver would register with Windows the addresses it listens to, and you would provide the port to which the physical toaster is connected. The driver would then ask Windows to send the commmand string it constructs using the assigned port when your program requests toast. Ideally, your driver would also notify Windows when the toast is done, so that the OS can tell your application program the status of the job.
In the Windows world, devices are not physical things, but software entities called drivers. The driver software does the actual manipulation of real objects, which adds layers of confusion for users trying to play with Device Manager. 
Writing drivers is a difficult job, and requires far more in depth knowledge of hardware than most programmers care to learn. The Windows DDK is a separate entity from the usual development tools because it is so specialized that very few developers need to use it. You could write your own driver for a mouse, but why bother? If you want to have some fun, buy a development kit for any programmable microcontroller and wire it into something useless - a beer cooler or something - then write a driver to monitor and control it. Then try to make it work reliably in a real world environment. That's where the fun begins...
"A Journey of a Thousand Rest Stops Begins with a Single Movement"
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
![Badger | [badger,badger,badger,badger...]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/badger.gif)
![Jig | [Dance]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/jig.gif)
