threading? cool! I want see the API! c++ std::thread? pthreads? something else?
via software interrupt? (hmm, that's something I would have to mull around in
my head)
just read this from int13h extended spec for EDD-3: "The BIOS is a single
threaded, master device". was hoping UEFI might provide for multithreading, but
saw
http://sourceforge.net/p/edk2/mailman/edk2-devel/thread/b28d412a-6798-4f5b-9803-84178a02a...@apple.com/
I guess UEFI and BIOS just provide basic single-threaded functionality.
Intel® Core™ i7 processor Extreme - Technical Documents
a find through the pdf manuals of the words thread and core and maybe mutex and
lock should provide much interesting info.
I am guesing that the user's thread code should implement a HLT instruction
when they are done with their thread? not sure. maybe not? running all threads
can heat up the cpu. on an i7-4960x, this could be a problem maybe because it's
a 220W proc - I have problems enough trying to liquid-cool my 150W proc (240mm
closed-loop, a 280mm closed-loop is available which provides 60% much better
cooling) and I am using 70% proc usage in the OS, so the OS is managing proc
usage (big companies/data centers do this to conserve on power consumption in
big buildings, for air conditioning etc, but I have to do this so my system
doesn't burn up).
threading will need to be throttled on some boxes - windows does this and it's
sparing my box when I do big parallel jobs. you will need something like
prime95 for cpu stress testing, maybe it can be ported to DOS. prime95 system
stress test
burn in for 4 hours. if cpu reaches I dunno, 10degc under max temp, throttle it
down and start the time over until you can reach 4 hours. takeds my box 20min
to rise when it's wrong. this was because case fans were wrong size and in
wrong directions for good airflow (I am still experimenting). I may just have
that side panel blow completely out rather than out and in and see if it's any
better.
>________________________________
> From: Eric Auer <e.a...@jpberlin.de>
>To: freedos-devel@lists.sourceforge.net
>Sent: Wednesday, July 9, 2014 12:25 PM
>Subject: Re: [Freedos-devel] Getting started
>
>
>
>Hi Andy,
>
>> Thanks for the responses. I really don't have a project/idea in mind but
>> am looking to get my hands dirty and develop/work on/debug/poke anything
>> that needs to be done to improve the project.
>>
>> After looking at the FreeDOS roadmap (
>> http://www.freedos.org/wiki/index.php/FreeDOS_Road_Map) it seems like
>> working on developing automated regression tests (something I do most days)
>> would be beneficial to speed up releases. Has anyone looked into this
>> before? What would be things that would be most useful to be tested?
>
>This would be beneficial if there were frequent code changes, which is
>not the case. In my personal opinion, it might be more useful to help
>Mateusz keeping an eye on updated packages to wrap them up in FreeDOS
>structured ZIPs for his update and installation tool, so the users can
>have fresh software. Regarding regression tests: There ARE some tickets
>where it would indeed be interesting to find out in which svn version
>of kernel (or maybe command.com, not so many other svn-based sources)
>a certain bug showed up or went away. So in that sense, your plant for
>making automated VM images running automated tests CAN be useful :-)
>
>Let me see what else the page lists:
>
>> == An Analysis of FreeDOS Needs ==
>>
>> There are certain needs that the 1.0 release does not address. These are:
>> * Built-in networking and internet connectivity currently provided by add on
>> packages.
>> * Open source USB support through a built-in subsystem.
>> * Integrated protected mode programming currently provided by add on
>> packages.
>> * Native 32‑ and 64‑bit code base.
>
>Honestly all of the above work quite well as drivers (using config.sys
>device drivers or command line runnable TSR drivers) and looking at
>FD32 experiences, building DPMI directly into the DOS kernel only has
>minimal performance advantages, for example. Of course it is important
>to have a good COLLECTION of drivers for in particular basic USB device
>classes and in particular wired ethernet network, even if they are just
>drivers and not parts of the kernel.
>
>For protected mode and 32/64 bit addressing (and multi CPU core thread
>processing) the necessary low level programming can be very tricky, so
>we have to stay thankful to the few experts who maintain the drivers
>for EMS / XMS / VCPI / DPMI and related. The USB core is also complex,
>but at least for drivers for specific USB devices, I see more chances
>for less specialized programmers to contribute.
>
>> * New device drivers available in other operating systems.
>
>At the moment, for example MPXPLAY uses ported (Linux ALSA?) built-in
>sound hardware drivers, but the nature of the DOS game versus soundcard
>interaction makes providing drivers for those hard: Most games have the
>driver built-in, not exchangeable. There are proof of concept "virtual"
>hardware drivers which show a simplified SoundBlaster hardware to DOS
>games while sending the actual sound to other hardware, but they suffer
>from the same problem as the protected mode drivers above: Complexity.
>
>For printing, the basic I/O can be seen as printer port, USB or network
>topic (there are some native and ported tools for the latter) while the
>printer language is sort of covered by ports of GhostScript and similar
>but could probably gain from having more choice of methods. For example
>for basic "print screen" functionality, we have a tiny driver which can
>do greyscale PostScript, HP/PCL and ESC/P in old dialects, which in turn
>is more convenient than having to go through GhostScript batches first.
>
>Note that nevertheless, it is barely used: Most people seem to use DOS
>only to print text or use DOS in a VM where they can also use drivers
>and tools of the host operating system. In particular for games, it is
>way more common to use DOSBOX or DOSEMU than to use raw hardware now.
>By the way, there are cool drivers like VMSMOUNT which specifically do
>driver work for improving DOS interaction with for example VMWare VMs.
>
>> * Faster release cycle through automated regression testing.
>
>Might be interesting, see above :-)
>
>> == Proposed Road Map ==
>>
>> The proposed road map (as of 20 August 2010) is as follows:
>> * Automated regression testing will begin with version 1.1.
>> * Tightly integrated protected mode support will begin with version 1.2.
>> * Tightly integrated, protected mode networking, protected mode USB
>> subsystem will be part of 1.2
>> * Version 1.2 will begin to share device drivers from other open source
>> operating systems.
>> * Version 2.0 will migrate kernel to a portable code base to address 32- and
>> 64-bit machines.
>
>Note that this roadmap is somewhat old and can be seen as one of several
>possible ways to improve FreeDOS. It basically depends on availability
>and interest of developers and on what they enjoy to contribute :-)
>
>Regards, Eric
>
>
>
>
>------------------------------------------------------------------------------
>Open source business process management suite built on Java and Eclipse
>Turn processes into business applications with Bonita BPM Community Edition
>Quickly connect people, data, and systems into organized workflows
>Winner of BOSSIE, CODIE, OW2 and Gartner awards
>http://p.sf.net/sfu/Bonitasoft
>_______________________________________________
>Freedos-devel mailing list
>Freedos-devel@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/freedos-devel
>
>
>
------------------------------------------------------------------------------
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft
_______________________________________________
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel
