Driver Problems? Questions? Issues?
Put OSR's experience to work for you! Contact us for assistance with:
  • Creating the right design for your requirements
  • Reviewing your existing driver code
  • Analyzing driver reliability/performance issues
  • Custom training mixed with consulting and focused directly on your specific areas of interest/concern.
Check us out. OSR, the Windows driver experts.

Upcoming OSR Seminars:

Writing WDF Drivers I: Core Concepts, Nashua, NH 15-19 May, 2017
Writing WDF Drivers II: Advanced Implementation Tech., Nashua, NH 23-26 May, 2017
Kernel Debugging and Crash Analysis, Dulles, VA 26-30 June, 2017
Windows Internals & Software Driver Development, Nashua, NH 24-28 July, 2017


Go Back   OSR Online Lists > ntdev
Welcome, Guest
You must login to post to this list
  Message 1 of 19  
07 Jul 17 12:56
R0b0t1
xxxxxx@gmail.com
Join Date: 24 Mar 2017
Posts To This List: 49
Real Time Clock Devices

How are they managed? This kind of goes along with the question about watchdog timers. Are they typically handled by vendors and not really visible? I could likely mimic the alarm functionality using the ACPI subsystem and custom hardware and wake up a computer, but how do I provide an interface that interacts with waitable timers and provides a system time? R0b0t1.
  Message 2 of 19  
07 Jul 17 14:26
Tim Roberts
xxxxxx@probo.com
Join Date: 28 Jan 2005
Posts To This List: 11533
Real Time Clock Devices

R0b0t1 wrote: > How are they managed? This kind of goes along with the question about > watchdog timers. Are they typically handled by vendors and not really > visible? There are only a few standard implementations for system timers on Windows-based motherboards. The exact locations are identified in the ACPI DSDT and exposed with a standard PnP identifier. The HAL knows how to use these standard identifiers, and hooks them up to the kernel functions. In the IoT world, this is provided by the board support package (BSP). > I could likely mimic the alarm functionality using the ACPI subsystem > and custom hardware and wake up a computer, but how do I provide an > interface that interacts with waitable timers and provides a system > time? What's the real situation here? Do you have a new motherboard that isn't supported by the existing Windows HALs and drivers? You may need to create a board support package. That probably requires you to work with someone within Microsoft. https://developer.microsoft.com/en-us/windows/iot/docs/bsp -- Tim Roberts, xxxxx@probo.com Providenza & Boekelheide, Inc.
  Message 3 of 19  
07 Jul 17 14:53
R0b0t1
xxxxxx@gmail.com
Join Date: 24 Mar 2017
Posts To This List: 49
Real Time Clock Devices

On Fri, Jul 7, 2017 at 1:26 PM, Tim Roberts <xxxxx@probo.com> <xxxxx@lists.osr.com> wrote: > R0b0t1 wrote: >> How are they managed? This kind of goes along with the question about >> watchdog timers. Are they typically handled by vendors and not really >> visible? > > There are only a few standard implementations for system timers on > Windows-based motherboards. The exact locations are identified in the > ACPI DSDT and exposed with a standard PnP identifier. The HAL knows how > to use these standard identifiers, and hooks them up to the kernel > functions. In the IoT world, this is provided by the board support <...excess quoted lines suppressed...> Thanks, it seems like that answers my question. > >> I could likely mimic the alarm functionality using the ACPI subsystem >> and custom hardware and wake up a computer, but how do I provide an >> interface that interacts with waitable timers and provides a system >> time? > > What's the real situation here? Do you have a new motherboard that > isn't supported by the existing Windows HALs and drivers? You may need > to create a board support package. That probably requires you to work > with someone within Microsoft. The closest I can get to describing a reasonable situation which might happen is: I want to run Windows 10 IoT Core on a Raspberry Pi, but I want to add in a real time clock via either the I2C or SPI bus. How do I make sure it is visible to the system? I think your link to the description of BSPs gives most of what is publicly available, but what if I am not a hardware or silicon vendor but I have access to the hardware and documentation at such a level to provide what is in a BSP? Another example would be HardKernel's ODROID-XU4 or other devices. An open ended bootloader signed by a valid key is provided as well as all hardware description necessary for compiling a Linux kernel. Ostensibly a third party could create a BSP if the information needed to do so is available. R0b0t1.
  Message 4 of 19  
07 Jul 17 16:10
Tim Roberts
xxxxxx@probo.com
Join Date: 28 Jan 2005
Posts To This List: 11533
Real Time Clock Devices

R0b0t1 wrote: > > I think your link to the description of BSPs gives most of what is > publicly available, but what if I am not a hardware or silicon vendor > but I have access to the hardware and documentation at such a level to > provide what is in a BSP? The Windows IoT team at Microsoft has been extremely interested in reaching out to the hardware development community -- not surprising, since they're trying to build an installed base. I suggest you start here, and try some of the contact links. I suspect you'll quickly find someone who can point you to the right resources. https://developer.microsoft.com/en-us/windows/iot/community -- Tim Roberts, xxxxx@probo.com Providenza & Boekelheide, Inc.
  Message 5 of 19  
08 Jul 17 06:34
R0b0t1
xxxxxx@gmail.com
Join Date: 24 Mar 2017
Posts To This List: 49
Real Time Clock Devices

On Fri, Jul 7, 2017 at 3:10 PM, Tim Roberts <xxxxx@probo.com> <xxxxx@lists.osr.com> wrote: > R0b0t1 wrote: >> >> I think your link to the description of BSPs gives most of what is >> publicly available, but what if I am not a hardware or silicon vendor >> but I have access to the hardware and documentation at such a level to >> provide what is in a BSP? > > The Windows IoT team at Microsoft has been extremely interested in > reaching out to the hardware development community -- not surprising, > since they're trying to build an installed base. I suggest you start <...excess quoted lines suppressed...> I was able to find https://docs.microsoft.com/en-us/windows-hardware/manufacture/iot/create-a-new-bs p which is about modifying the RPi3 BSP. Unfortunately there doesn't seem to be much in the way of nontrivial examples. More searching I did related to RTC drivers (perhaps they are given a driver class?) didn't turn up anything but very, very old results related to WinCE. Having tried the MSDN Forum and the Windows Feedback Tool and found them to have poor response times, I suspect social media may be the best way to follow up. The WindowsIoT account is defunct, so I will be asking IoTDan about BSPs and the RTC subsystem soon. Please wish me luck in my use of social media. I'll reply with any useful information I might find so it's archived on the list. R0b0t1.
  Message 6 of 19  
09 Jul 17 08:20
Pavel A
xxxxxx@fastmail.fm
Join Date: 21 Jul 2008
Posts To This List: 2389
Real Time Clock Devices

R0b0t1 wrote: > Please wish me luck in my use of social media. Gladly. Even more - good luck with the MS IoT for anything useful at all. -- pa
  Message 7 of 19  
09 Jul 17 09:54
Peter Viscarola (OSR)
xxxxxx@osr.com
Join Date:
Posts To This List: 5906
List Moderator
Real Time Clock Devices

>good luck with the MS IoT for >anything us full at all. Now, why would you say that? IoT Enterprise is just Windows Embedded by another name, and thus generically useful. Other variants of IoT work on a wide variety of hardware and have some pretty cool features, especially if you're concerned with pushing collected data up to the cloud. Drivers on IoT are just Windows drivers... and, yes, there's the whole UWP thing, but in terms of that... well... that's whole other thread. Peter OSR @OSRDrivers
  Message 8 of 19  
10 Jul 17 01:34
R0b0t1
xxxxxx@gmail.com
Join Date: 24 Mar 2017
Posts To This List: 49
Real Time Clock Devices

On Sun, Jul 9, 2017 at 7:19 AM, xxxxx@fastmail.fm <xxxxx@lists.osr.com> wrote: > R0b0t1 wrote: >> Please wish me luck in my use of social media. > > Gladly. Even more - good luck with the MS IoT for anything useful at all. Well, I mostly hold the same opinion, but it could very well speed up development time and make my employer more comfortable with embedded development. There are, after all, more Windows, and specifically C# programmers, available than most other demographics. However my experience has been that Windows programs (and programmers?) are generally of a lesser quality overall than Linux or POSIX programs (or programmers). I continue to explore Windows due to its pervasive workplace presence and to keep my skills up to date across the board* but am still not finding any counterexamples. As a consequence I don't think * I had to spend a little over a month relearning Windows after using Linux for multiple years in a row. It wasn't pleasant and most of what I did was make Windows more like my Linux installation. On Sun, Jul 9, 2017 at 8:53 AM, xxxxx@osr.com <xxxxx@lists.osr.com> wrote: >>good luck with the MS IoT for >>anything us full at all. > > Now, why would you say that? > > IoT Enterprise is just Windows Embedded by another name, and thus generically useful. > I have to agree with this sentiment because I wouldn't be bothering to learn about Windows IoT if it seemed devoid of all value. > Other variants of IoT work on a wide variety of hardware and have some pretty cool features, especially if you're concerned with pushing collected data up to the cloud. > My experience with Microsoft software indicates that - despite a few moments of truly inspired and comprehensive design - the majority of the APIs and software that is available is lacking in some way or another. I recently had a conversation about this and I think the best way to explain it is that the APIs and software seem like they were never actually used for their intended purpose by someone within Microsoft, and as a consequence nobody ever found out how they were deficient. But I have no doubt they passed all of their test cases. In this case Microsoft's take on IoT seems to revolve around things like "Big Data" and "the cloud" which, while I could agree are actual terms, are far more limited and probably not what is applicable to most people. > Drivers on IoT are just Windows drivers... and, yes, there's the whole UWP thing, but in terms of that... well... that's whole other thread. > As far as I can like Windows I rather like the idea of a unified platform, but I'm having a problem figuring out what kind of promises it actually makes - a quick reading about it indicates it's not much different than what Linux already has. The most applications that do not interact with hardware directly will run without modification, but for everything else, you are designing for a specific hardware product. As for my question to IoTDan, I have received no response. His Twitter account seems work oriented so I hope to receive a reply this coming week. If I don't receive a reply I'm rather concerned I will not obtain the information I need in a timely manner. I will keep looking, as I've found some better results using terminology introduced to me on the list before, but ultimately I don't seem to be having great luck with low level Windows development. I believe I've complained about the state of Microsoft provided documentation before on the list. If Microsoft is taking their IoT initiative seriously like Peter suggested, hopefully that will produce some documentation effort that spills over onto other low level windows subsystems.
  Message 9 of 19  
10 Jul 17 13:05
anton bassov
xxxxxx@hotmail.com
Join Date: 16 Jul 2006
Posts To This List: 4349
Real Time Clock Devices

> There are, after all, more Windows, and specifically C# programmers, available than >most other demographics. Developers, developers, developers,developers.....(N more time)....developers. Yes!!!! > However my experience has been that Windows programs (and programmers?) are >generally of a lesser quality overall than Linux or POSIX programs (or programmers). Don't you even start...... > In this case Microsoft's take on IoT seems to revolve around things like "Big Data" > and "the cloud" which, while I could agree are actual terms, are far more limited > and probably not what is applicable to most people. Ironically, the workable concept of IoT in itself seems to be tightly related to "Big Data". All "futuristic projections" (like,for example, a "smart fridge" that may automatically order items over the Internet, a house with self-adjusting heating et al) don't seem to be coming true not because of some technical challenges but simply because all these "fancy" things seem to be of zero interest to the average end user. At the same time it may be, indeed, interesting for the corporate customers who have to collect and analyze data and may want to automate this process. For example, consider a utility company that reads "smart" electricity/water meters over the Internet - unlike above mentioned "projections" this is,indeed, a useful thing that offers convenience and cost reduction. Therefore,MSFT is probably looking in the right direction Anton Bassov
  Message 10 of 19  
10 Jul 17 13:15
Don Burn
xxxxxx@windrvr.com
Join Date: 23 Feb 2011
Posts To This List: 1330
Real Time Clock Devices

Peter, The problem with Windows IOT is more the way Microsoft presents it to customers. I have several customers who have used Windows embedded and after talking to Microsoft about IOT got the impression, that the system would not work if it was not connected to an Azure cloud. I tried to explain otherwise, but the impression the Microsoft field people give, is enough that several have said we are not going there. The other problem with IOT is the moving target problem of supported platforms. I had a customer start coding for IOT (I was not involved with the effort) since their embedded board was going to be supported according to Redmond. A few months later there is a revised list of platforms sent to them, and their system is not supported. Don Burn Windows Driver Consulting Website: http://www.windrvr.com -----Original Message----- From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@osr.com xxxxx@lists.osr.com Sent: Sunday, July 09, 2017 9:53 AM To: Windows System Software Devs Interest List <xxxxx@lists.osr.com> Subject: RE:[ntdev] Real Time Clock Devices >good luck with the MS IoT for >anything us full at all. Now, why would you say that? IoT Enterprise is just Windows Embedded by another name, and thus generically useful. Other variants of IoT work on a wide variety of hardware and have some pretty cool features, especially if you're concerned with pushing collected data up to the cloud. Drivers on IoT are just Windows drivers... and, yes, there's the whole UWP thing, but in terms of that... well... that's whole other thread. Peter OSR @OSRDrivers --- NTDEV is sponsored by OSR Visit the list online at: <http://www.osronline.com/showlists.cfm?list=ntdev> MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers! Details at <http://www.osr.com/seminars> To unsubscribe, visit the List Server section of OSR Online at <http://www.osronline.com/page.cfm?name=ListServer>
  Message 11 of 19  
10 Jul 17 14:06
Peter Viscarola (OSR)
xxxxxx@osr.com
Join Date:
Posts To This List: 5906
List Moderator
Real Time Clock Devices

In terms of IoT "issues"... I agree with BOTH of Mr Burn's statements. IoT is marketed very clumsily by MSFT(if I'm invited to one more talk about IoT that turns out to be mostly focused on Azure I'm going to scream). Conflating embedded with IoT is folly. There are IoT uses for embedded; there are many other non-IoT uses for embedded... so why call "embedded" IoT? Argh! The hardware support story is also more than a little chaotic. Had a client that was beeegggggiiiinnnngg for support of a specific platform, for many months, that was repeatedly told "no way".... they even offered to do the bsp themselves.... just a few weeks later, they discovered the board would be officially supported by IoT after all. Yay!? Now, the fact that IoT supports the desired platform isn't a BAD thing. It's just.... frustrating when you're over on this end trying to, you know, build products to sell to people. I really don't know how you fix the platform issue when so many folks need to come together, by a wide variety of possible paths, to realize support for a given platform. Anybody can create a BSP for a given platform today... assuming you have all the data you need from the silicon vendor, and a lot of Windows OS expertise. Peter OSR @OSRDrivers
  Message 12 of 19  
10 Jul 17 15:29
R0b0t1
xxxxxx@gmail.com
Join Date: 24 Mar 2017
Posts To This List: 49
Real Time Clock Devices

On Mon, Jul 10, 2017 at 1:06 PM, xxxxx@osr.com <xxxxx@lists.osr.com> wrot= e: > In terms of IoT "issues"... I agree with BOTH of Mr Burn's statements. Io= T is marketed very clumsily by MSFT(if I'm invited to one more talk about I= oT that turns out to be mostly focused on Azure I'm going to scream). Conf= lating embedded with IoT is folly. There are IoT uses for embedded; there a= re many other non-IoT uses for embedded... so why call "embedded" IoT? Arg= h! > > The hardware support story is also more than a little chaotic. Had a clie= nt that was beeegggggiiiinnnngg for support of a specific platform, for man= y months, that was repeatedly told "no way".... they even offered to do the= bsp themselves.... just a few weeks later, they discovered the board would= be officially supported by IoT after all. Yay!? Now, the fact that IoT su= pports the desired platform isn't a BAD thing. It's just.... frustrating w= hen you're over on this end trying to, you know, build products to sell to = people. > This is essentially my experience with driver development, and looking into adding support to IoT Core to 3rd party devices. I want to do it and might have the time to do it but I don't have the information to do it. > I really don't know how you fix the platform issue when so many folks nee= d to come together, by a wide variety of possible paths, to realize support= for a given platform. Anybody can create a BSP for a given platform today= ... assuming you have all the data you need from the silicon vendor, and a = lot of Windows OS expertise. > I didn't join this list to evangelize about open source, but I think you have come across one of the reasons why open source is so successful: there are no artificial barriers to development. If I have a problem I can address it directly by reading the program to find the information I need, and if it makes sense, modify the behavior of that program. R0b0t1.
  Message 13 of 19  
10 Jul 17 15:41
Peter Viscarola (OSR)
xxxxxx@osr.com
Join Date:
Posts To This List: 5906
List Moderator
Real Time Clock Devices

>This is essentially my experience with driver development... I think we've tangled on this before. All the data you need to write a Windows driver is available in MSDN. The less said reviving this topic, the better... >I didn't join this list to evangelize about open source Super good choice, that. ;-) The problem with adding support for a platform isn't much related to "How do I write a Windows BSP?" It's more related to having access to the silicon vendor' magic juju. The sources for the RPI BSP (or some BSP, anyhow) are on GitHub... and, though I have not done it myself, I'm told by people who HAVE personally done it that they really are sufficient to allow you to create your own BSP for a platform of your choice, ASSUMING you have the requisite info from the silicon provider. Peter OSR @OSRDrivers
  Message 14 of 19  
10 Jul 17 15:41
Pavel A
xxxxxx@fastmail.fm
Join Date: 21 Jul 2008
Posts To This List: 2389
Real Time Clock Devices

> Now, why would you say that? Peter, Because the churn rate of their technologies is disturbing. I wanted to write something about opensource vs "shared source" and so on - but yesterday watched Guardians of the Galaxy 2 ... that final scene where Chris Pratt gets Zune player for his lost Walkman? It says all. That scene made me weep. So, it's Zune. Their idea of IoT platform itself is very appealing. Small versatile devices connected to cloud backend, supported by powerful cloud services, device management, patches, updates - all this is great. But... this all is available from others. Why to take the high risk of investing in technology that may vanish in any moment? -- pa
  Message 15 of 19  
10 Jul 17 15:51
R0b0t1
xxxxxx@gmail.com
Join Date: 24 Mar 2017
Posts To This List: 49
Real Time Clock Devices

On Mon, Jul 10, 2017 at 2:40 PM, xxxxx@osr.com <xxxxx@lists.osr.com> wrote: >>This is essentially my experience with driver development... > > I think we've tangled on this before. All the data you need to write a Windows driver is available in MSDN. The less said reviving this topic, the better... > I'm not going to bring it up again in length, but the only useful examples I found were not provided by Microsoft or OSR. They were simply people, and one of them cited paid development experience with Microsoft products. Based from most postings on this list it seems the majority of people have a huge support infrastructure of private code, documentation, and expertise to back them up. >>I didn't join this list to evangelize about open source > > Super good choice, that. ;-) > > The problem with adding support for a platform isn't much related to "How do I write a Windows BSP?" It's more related to having access to the silicon vendor' magic juju. > Per the original question it's not necessarily how to write the BSP, but how to create a driver that interacts with what is, to my knowledge, a fairly undocumented portion of the Windows kernel. R0b0t1.
  Message 16 of 19  
10 Jul 17 15:53
Peter Viscarola (OSR)
xxxxxx@osr.com
Join Date:
Posts To This List: 5906
List Moderator
Real Time Clock Devices

>this all is available from others. If the Windows alternative does not offer appreciable perceived advantages over other platforms, then MSFT is probably screwed. That's not even a MSFT-specific statement, it's a given for any technology: If Technology A does not offer appreciable benefits over Technology B, then technology A is probably screwed. The benefit doesn't need to even be a technical bnefit... it doesn't need to be a real benefit.... it just needs to be a perceived benefit. I dunno... I admit that the entire space is very confusing. And I don't see MSFT bringing a laser-like focus to guide us. Peter OSR @OSRDrivers
  Message 17 of 19  
10 Jul 17 15:58
Peter Viscarola (OSR)
xxxxxx@osr.com
Join Date:
Posts To This List: 5906
List Moderator
Real Time Clock Devices

But if your goal is to change the source the OS uses as it's clock... isn't that part of the BSP? I dunno... I readily admit to not having looked into what you're trying to do. I'll also read I,y admit that adding an RTC to the RPI would seem a reasonable thing to want to do. If you just want to query it for your own app, that's not a hard driver to write. If you want to integrate it into the OS as the time source used by the OS in place of whatever it already uses, that is by necessity a different and much larger task. Peter OSR @OSRDrivers
  Message 18 of 19  
10 Jul 17 20:25
R0b0t1
xxxxxx@gmail.com
Join Date: 24 Mar 2017
Posts To This List: 49
Real Time Clock Devices

On Mon, Jul 10, 2017 at 2:58 PM, xxxxx@osr.com <xxxxx@lists.osr.com> wrot= e: > But if your goal is to change the source the OS uses as it's clock... isn= 't that part of the BSP? > Right, and the guidance and verbiage you gave specifically to BSPs made me feel stupid for not finding better answers sooner. > I dunno... I readily admit to not having looked into what you're trying t= o do. I'll also read I,y admit that adding an RTC to the RPI would seem a = reasonable thing to want to do. If you just want to query it for your own = app, that's not a hard driver to write. If you want to integrate it into t= he OS as the time source used by the OS in place of whatever it already use= s, that is by necessity a different and much larger task. > Well - if you could give me some words or do a few quick searches yourself I've still not found anything on how to actually plumb a driver to the time subsystem. What you say is true, I could just communicate with my device directly, but I'm wondering how I get it to store the system time and provide interrupts to wake up the machine that can, presumably, be accessed with already available WinAPI (waitable timers, but I am guessing). In other news Dan hasn't chosen to reply this Monday so it's possible he doesn't care to answer, but I'll keep an eye on it throughout the week. I might try some other forums. R0b0t1.
  Message 19 of 19  
11 Jul 17 19:56
M M
xxxxxx@hotmail.com
Join Date: 21 Oct 2010
Posts To This List: 737
Real Time Clock Devices

Do you really want to control the system time from your device or just provide yourself with a reliable ?call me every X? facility? If you want to control the system clock, then you want to look at Windows Time Providers (https://msdn.microsoft.com/en-us/library/windows/desktop/ms725475(v=vs.85).aspx) This is a UM API that will allow you to provide time samples into Windows built in time provider service that ultimately controls the clock and tries to prevent skew versus wall clock time If you are trying to control the clock used by the kernel to control thread scheduling, this used to be the domain of the HAL but I have not looked into this in more than a decade so much may have changed. If you are looking to provide your code with a periodic interrupt, then that is the easiest of all ? just as long as your period and granularity aren?t too tight or missing a few doesn?t cause the nuclear missiles to launch. Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10 From: R0b0t1<mailto:xxxxx@gmail.com> Sent: July 10, 2017 8:25 PM To: Windows System Software Devs Interest List<mailto:xxxxx@lists.osr.com> Subject: Re: [ntdev] Real Time Clock Devices On Mon, Jul 10, 2017 at 2:58 PM, xxxxx@osr.com <xxxxx@lists.osr.com> wrote: > But if your goal is to change the source the OS uses as it's clock... isn't that part of the BSP? > Right, and the guidance and verbiage you gave specifically to BSPs made me feel stupid for not finding better answers sooner. > I dunno... I readily admit to not having looked into what you're trying to do. I'll also read I,y admit that adding an RTC to the RPI would seem a reasonable thing to want to do. If you just want to query it for your own app, that's not a hard driver to write. If you want to integrate it into the OS as the time source used by the OS in place of whatever it already uses, that is by necessity a different and much larger task. > Well - if you could give me some words or do a few quick searches yourself I've still not found anything on how to actually plumb a driver to the time subsystem. What you say is true, I could just communicate with my device directly, but I'm wondering how I get it to store the system time and provide interrupts to wake up the machine that can, presumably, be accessed with already available WinAPI (waitable timers, but I am guessing). In other news Dan hasn't chosen to reply this Monday so it's possible he doesn't care to answer, but I'll keep an eye on it throughout the week. I might try some other forums. R0b0t1. --- NTDEV is sponsored by OSR Visit the list online at: <http://www.osronline.com/showlists.cfm?list=ntdev> MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers! Details at <http://www.osr.com/seminars> To unsubscribe, visit the List Server section of OSR Online at <http://www.osronline.com/page.cfm?name=ListServer> --
Posting Rules  
You may not post new threads
You may not post replies
You may not post attachments
You must login to OSR Online AND be a member of the ntdev list to be able to post.

All times are GMT -5. The time now is 16:45.


Copyright ©2015, OSR Open Systems Resources, Inc.
Based on vBulletin Copyright ©2000 - 2005, Jelsoft Enterprises Ltd.
Modified under license