From: assemblywizard@gmail.com   
      
   Oh gesus--keep on the ego trip guy... if that all works for you have at   
   it... I simply don' t have the time for this stuff...  have a nice   
   day...   
      
   John   
      
   "Marco van de Voort"  wrote in message   
   news:slrnda3pvk.1sgh.marcov@snail.stack.nl...   
   > On 2005-06-03, John Smith  wrote:   
   >> Yep, used to have to do it... you take time slices from a processor   
   >> which is already time slicing,   
   >   
   > What where how ? Anything I do takes timeslices. However it takes them   
   > from   
   > the OS scheduler, not the processor. What are you talking about anyway   
   > ?   
   >   
   >> you have to synchronize to get good   
   >> performance,   
   >   
   > What synchronization, where, how? I don't have to synchronize for a   
   > kernel   
   > call. The kernel scheduler will block if necessary, and will unblock   
   > if   
   > needed. Nothing async about it that needs syncing.   
   >   
   >> you force overhead on the processor to push and pull registers on its   
   >> stack...   
   >   
   > That's needed for every IPC call, including kernel. The kernel will   
   > handle   
   > did, if needed at all, since usually regs are not already saved for   
   > parameter transfer.   
   >   
   >> and there are strict rules to doing it successfully enough to be   
   >> able to turn out a retail product... if you are just hacking about--a   
   >> crash now and then is no real problem...   
   >   
   > That's so general in software development, that it applies to pretty   
   > much   
   > everything. It is like saying that water is wet.   
   >   
   >> Most when they first learn enough assembly to be dangerous see   
   >> everything as an assembly problem,   
   >   
   > Of course. But calling the kernel directly from userland usually   
   > pretty much   
   > is an problem to which assembler is at least relevant. OS ABI etc.   
   >   
   > Moreover it was just as example that other OSes also use ints (read:   
   > kernel   
   > calls), that the principle is not dos-specific at all.   
   >   
   >> after about 20 years of professional   
   >> paid programming and gaining senior status, you spend a lot of time   
   >> doing such things...   
   >   
   > What things? Recognizing a system call? Ranting about sites without   
   > actually   
   > reading what it is about?   
   >   
   >> Most of the time, you will want to call kernel code and let the   
   >> processor handle things for you,   
   >   
   > Well, that is pretty much logical for a system call isn't it?   
   > Specially   
   > if a different name for syscall is _KERNELCALL_.   
   >   
   >> usually much more efficient unless you have a team of senior   
   >> programmers   
   >> you can spare...   
   >   
   > A kernel call is totally separate from performance or processor. It is   
   > about   
   > privilege levels.   
   >   
   >> only time assembly is a real shinning star is the example   
   >> I provided--that is, when there is simply no other way to accomplish   
   >> the   
   >> task, in windows the api is very complete   
   >   
   > Assembly and API use are not correlated. Specially since the assembler   
   > site   
   > I referenced _is_ about calling the kernel (hence API)   
   >   
   >>... if you just built a new printer, scanner, camera, mp3 device,   
   >>etc...   
   >> you will need at least the ddk to begin and possibly, you may even   
   >> need to   
   >> drop to assembly to accomplish a task   
   >   
   > The whole point of the ddk is to not make that 100% necessary. Still   
   > can   
   > be important out of performance reasons though for high speed devices,   
   > but   
   > that must be a decision based on profiling.   
   >   
   >>... in linux there are similar libraries which are available from 3rd   
   >>party   
   >> vendors   
   >   
   > Linux.... 3rd party vendors ... ? For bloody what? Driver (read:   
   > Kernel   
   > module) enhancement? Which third party vendor makes linux then do you   
   > think?   
   > :) The whole kernel src is available and that is the DDK at the same   
   > time.   
   >   
   >>  which have been well road tested and debugged... Warmest regards,   
   >   
   > I wonder if you even have a clue about Linux (or *nix in general) at   
   > all.   
   >   
   > If I seem harsh, it is because your message was a totally useless   
   > rant, with   
   > clear indication that you didn't even bothered to look or try to   
   > understand   
   > what I was saying.   
   >   
   > The fact that you haven't contributed anything useful yet in all your   
   > msgs   
   > is also not helping, as is your top-posting   
   >   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)