I would love to use VS2005 as an IDE for embedded development. Unfortunately, certain things are easy with VC6 and nmake, but awkward or impossible with VS2005 and VCBuild.
I was unable to setup my cross-compiler. With VS2005 it's possible to override the rule for *.c files and specify an alternate compiler, but there is no way (in beta2) to replace the built-in rule for *.o files and use an alternate linker. VC++ "custom build rules" are insufficient because they only act upon files that appear in the project, not files that are generated as output from a previous build stage. There are some half-baked workarounds like adding "dummy" *.o files to the project, but nothing I've found reasonable.
The MSBuild system looks awesome, but VC++ 2005 only has support for the VCBuild subset. It's a lot more limiting, and something to keep in mind.
As other people have mentioned, FPSE is obsolete. Today, you are supposed to use client-side dynamic (webbot, DTC, add-in) or more modern server-side dynamic (ASP) techniques. A lot of things including navigation can be handled design-time, reply or email if you're interested in that topic. I do everything design-time; it's my preferred method, and FP2003 is my preferred tool.
However you can still use a webbot for server-side dynamic behavior. Visit MSDN and download the Frontpage 2002 SDK. Don't worry, it's not outdated. The extensibility models haven't changed between versions.
The SDK describes the four ways a webbot can activate. Try to test things client-side first, it's a lot easier. If your webbot fails it will just insert a generic [FrontPage Component name] on the page. Doublecheck the logs in _vti_pvt for the logs, to get hint why things are failing.
It's oldschool, it works, and it's a simple variant on CGI scripting. Again, for simple things like navigation bars it's a heck of a lot easier to use a design-time dynamic control (client-side webbot, DTC, or add-in). I strongly recommend you consider those instead.
. . . that is is important for companies to phase out their old product lines in favor of newer, more usable technologies. It is hard for the consumers, as they are the party who must then buy the new things, but in the long run it is quite good for the industry.
That might be an ok view in the home-PC market, but the point was that this move affects the embedded market. The goal of that market is smaller, cheaper, lower power. One motivation to use the 486 might be extremely low engineering costs. Vendors like AmPro (among others) will sell a single-board PC; that might be a good solution if lots of existing code and hardware can be used to save engineering time. Although Megatouch XL uses fancier hardware today, a few years ago many of the bartop touch-screen poker games were using those older 486 processors.
I agree, the AMD 486 disappearing probably really doesn't hurt anything except the x86 embedded market which is fairly small anyway. 68k, MPC8xx, or especially 8051 disappearing would be more devastating (and foolish since they generate tons of sales). However, since theres no reason to change, except the parts going out of production, change really isn't "for the best"
Embedded applications need single-purpose, low-cost, low-power, fast time-to-market, small-footprint solutions. If the 486 is able to run that dishwasher or microwave effectively, your "out with the old in with the new" attitude will only pass on added cost to the consumer.
Every tenth word file fails when you double-click on it the first time. But when you double-click again it opens fine. And you are able to double click on the document icons at a rate of over 1,000,000,000 every second.
That is a much better explanantion, and now in respone to the original comment: it is nearly impossible to criticize that "miss rate" without actually going through the design process.
Something like Patterson & Hennessy would explain the classic tradeoff well. If you make a lower miss rate (imagine 9.5 out of 10 are hits), the time for hits goes up slightly. Now the main question becomes, what is the "common case".
The most important thing before you whine about some processor is to know the design process. Is missing 1 out of 20 times (but hit-time taking twice as long) better? Is missing 1 out of 7 times (but having a lightning-fast hit-time and tolerable miss-time) better? As a/.er there's really no room to say "thats so bad" unless you actually sat at Intel/AMD, went through the design process, and there was a better option for your mix of instructions.
Typically the came Computer Space is considered the first "arcade" game because it set precedent for all future games: coin accepting, dedicated unit instead of multipurpose computer, display, controls, etc.
Check www.klov.com or www.arcadehistory.com for more info, or if you'd like to chat about the classics hit #rgvac on EFNet. Also usenet rec.games.video.arcade.collecting
Slashdot Mirror
I would love to use VS2005 as an IDE for embedded development. Unfortunately, certain things are easy with VC6 and nmake, but awkward or impossible with VS2005 and VCBuild.
I was unable to setup my cross-compiler. With VS2005 it's possible to override the rule for *.c files and specify an alternate compiler, but there is no way (in beta2) to replace the built-in rule for *.o files and use an alternate linker. VC++ "custom build rules" are insufficient because they only act upon files that appear in the project, not files that are generated as output from a previous build stage. There are some half-baked workarounds like adding "dummy" *.o files to the project, but nothing I've found reasonable.
The MSBuild system looks awesome, but VC++ 2005 only has support for the VCBuild subset. It's a lot more limiting, and something to keep in mind.
As other people have mentioned, FPSE is obsolete. Today, you are supposed to use client-side dynamic (webbot, DTC, add-in) or more modern server-side dynamic (ASP) techniques. A lot of things including navigation can be handled design-time, reply or email if you're interested in that topic. I do everything design-time; it's my preferred method, and FP2003 is my preferred tool.
However you can still use a webbot for server-side dynamic behavior. Visit MSDN and download the Frontpage 2002 SDK. Don't worry, it's not outdated. The extensibility models haven't changed between versions.
With a perl script, it's the same as a standard CGI script as described on MSDN. Look for the example \FPSDK\Files\WebBot\wbtest4 in the SDK. If you prefer to use a DLL or shared library, use the BeginWebBotExpand macro which lets you access the bot attributes. In either case, you're going to build a BTL file and call the webbot from HTML like:
The SDK describes the four ways a webbot can activate. Try to test things client-side first, it's a lot easier. If your webbot fails it will just insert a generic [FrontPage Component name] on the page. Doublecheck the logs in _vti_pvt for the logs, to get hint why things are failing.
It's oldschool, it works, and it's a simple variant on CGI scripting. Again, for simple things like navigation bars it's a heck of a lot easier to use a design-time dynamic control (client-side webbot, DTC, or add-in). I strongly recommend you consider those instead.
That might be an ok view in the home-PC market, but the point was that this move affects the embedded market. The goal of that market is smaller, cheaper, lower power. One motivation to use the 486 might be extremely low engineering costs. Vendors like AmPro (among others) will sell a single-board PC; that might be a good solution if lots of existing code and hardware can be used to save engineering time. Although Megatouch XL uses fancier hardware today, a few years ago many of the bartop touch-screen poker games were using those older 486 processors.
I agree, the AMD 486 disappearing probably really doesn't hurt anything except the x86 embedded market which is fairly small anyway. 68k, MPC8xx, or especially 8051 disappearing would be more devastating (and foolish since they generate tons of sales). However, since theres no reason to change, except the parts going out of production, change really isn't "for the best"
Embedded applications need single-purpose, low-cost, low-power, fast time-to-market, small-footprint solutions. If the 486 is able to run that dishwasher or microwave effectively, your "out with the old in with the new" attitude will only pass on added cost to the consumer.
That is a much better explanantion, and now in respone to the original comment: it is nearly impossible to criticize that "miss rate" without actually going through the design process.
Something like Patterson & Hennessy would explain the classic tradeoff well. If you make a lower miss rate (imagine 9.5 out of 10 are hits), the time for hits goes up slightly. Now the main question becomes, what is the "common case".
The most important thing before you whine about some processor is to know the design process. Is missing 1 out of 20 times (but hit-time taking twice as long) better? Is missing 1 out of 7 times (but having a lightning-fast hit-time and tolerable miss-time) better? As a /.er there's really no room to say "thats so bad" unless you actually sat at Intel/AMD, went through the design process, and there was a better option for your mix of instructions.
Typically the came Computer Space is considered the first "arcade" game because it set precedent for all future games: coin accepting, dedicated unit instead of multipurpose computer, display, controls, etc. Check www.klov.com or www.arcadehistory.com for more info, or if you'd like to chat about the classics hit #rgvac on EFNet. Also usenet rec.games.video.arcade.collecting