Windows XP Embedded или Embedded Linux?

Любопытная статья. Микросакс поливает грязью Линукс, в конце автором развенчивается коварность Microsoft:)))

Re: Windows XP Embedded или Embedded Linux?

Да, прекольненькая статейка 🙂

Re: Windows XP Embedded или Embedded Linux?

> Уникальность: пакет технологий, ориентированный на разработку устройств следующего поколения.

Обычный пиар M$, после которого их хвалу XP можно дальше не читать, ибо дальше сплошные маркетологические бредни.

Re: Windows XP Embedded или Embedded Linux?

Статья — PR-дуэль между Microsoft и Lineo. И, судя по:

> Фирма Lineo полагает, что специалистам компании Microsoft следовало бы ознакомиться с последней версией Linux-ядра за номером 2.4

Re: Windows XP Embedded или Embedded Linux?

2.6 на встраиваемых системах, насколько я знаю, пока не используется

Re: Windows XP Embedded или Embedded Linux?

Статья расчитана на тех кто Windows XP Embedded в глаза не видел, так как те кто с ней работал, знают какое это гамно, равно как глючные и на редкость не удобные средства разработки. Да и что это за embedded система если она как минимум около 140Мб на носителе занимает и по крайней мере 256Мб памяти требует. А стабильность её схожа с карточным домиком. Не сурьёзно.

Re: Windows XP Embedded или Embedded Linux?

> 2.6 на встраиваемых системах, насколько я знаю, пока не используется

Montavista Linux 4.0 основан на 2.6. Патчи -tiny для 2.6 делались, насколько я знаю, для какого-то поставщика встроенных систем.

Re: Windows XP Embedded или Embedded Linux?

знаю одну российскую фирму, которая еще 2 года назад толкала Embedded системы (регистраторы аварийных процессов) на Win 3.1 и win 95:))))

Глюкалово то еще было

Re: Windows XP Embedded или Embedded Linux?

Тебе приходилось с XP Embedded работать? Видимо нет, иначе ты бы немного иначе писал бы.

Re: Windows XP Embedded или Embedded Linux?

Ты видимо также в глаза никогда XP Embedded не видел. Лично я использую MVL, но соседний отдел занимается XPE и я знаю, что твои слова далеки от истины. Зачем это красноглазие?

Re: Windows XP Embedded или Embedded Linux?

А под Linux ты глюкалова никогда не видел?

Re: Windows XP Embedded или Embedded Linux?

Не-а. МТК.30 с Linux на ядре 2.4 рулит. А с XP Embedded не работал

Re: Windows XP Embedded или Embedded Linux?

Думаю, что они рулят примерно одинаково 🙂 Нет в мире совершенства 🙂

Re: Windows XP Embedded или Embedded Linux?

>Нет в мире совершенства 🙂

Эт точно. И долбаный производитель не желает на ядро 2.6 переходить, мотивируя это тем, что никто не переходит:-)

Re: Windows XP Embedded или Embedded Linux?

Ну и что, что-нить интегрировать не пробывал? Попробуй сделай импорт reg-файла в компоненту и удивись сожраным пробелам в именах ключей — а если этих ключей сотни (ICA Citrix)? А то что не все зависимости среди компонентов разруливаются и на что Микрософт официально советует использовать try-and-error принцип, обосновывая тем, что мол трудно всё разрулить при 11-тыс. компонентах? А как же Линукс дистрибуторы при примерно том же кол-ве пакетов всё разруливают? А как вам апдейт концепт ХРЕ, которого просто нет и многие используют для этого Линукс? А я ещё забыл про классный team work концепт, который предусмотрен для teams состоящих из ровно одного разработчика. Про version control системы тоже никто особено не задумывался (может о них никто не знает в Микрософте). Лично у меня сложилось впечатление, что всё это хозяйство делалось горсткой не отягощёных опытом и талантом студентов лишёных всякого плана.

Re: Windows XP Embedded или Embedded Linux?

>Про version control системы тоже никто особено не задумывался (может о них никто не знает в Микрософте).
Я и не думал, что там всё так плохо. Многие линь на офисные серваки ставят ради svn. я думал всё почему.

Re: Windows XP Embedded или Embedded Linux?

Ну почему же. У MS есть Visual Source Safe — типа система контроля версий. Но от её использования просто нет слов, одни эмоции.

Пробуем Windows Embedded Standard 7 — версию Windows 7, которая будет получать обновления еще год

Последнее время среди пользователей Windows 7 царит уныние и расстройство, ведь с 14 января 2020 года Microsoft прекратит ее поддержку. Неплохая операционная система была, но всему свое время, надо давать дорогу молодым.
Windows 7 начала свой путь 22 октября 2009 года, то есть к 14 января 2020 будет уже больше 10 лет.

реклама

Что же делать тем пользователям, кто по тем или иным причинам не хочет уходить с Windows 7 на новую и продвинутую Windows 10? Ведь завершение поддержки — это смерть ОС. За год там накопится столько незакрытых уязвимостей, что пользоваться ею будет крайне опасно.

У меня есть старый ноутбук, Windows 7 для которого подходит гораздо лучше, чем Windows 10. Поэтому я тоже озаботился вопросом завершения поддержки Windows 7 и стал искать выход.

И выход нашелся, пусть и довольно неожиданный. Одна из редакций Windows 7, а именно — Windows Embedded Standard 7, будет получать обновления до 13 октября 2020 года, то есть еще больше года.

реклама

А ее редакции в виде Windows Embedded POSReady 7 и Windows Embedded Compact 7, будут получать обновления до 12 октября 2021 года и 13 апреля 2021 года соответственно.

Что же это за зверь такой — Windows Embedded и почему о нем мало кто слышал?

Microsoft Windows Embedded — семейство встраиваемых операционных систем Microsoft Windows для применения в специализированных устройствах. Существует несколько категорий продуктов для создания широкого спектра устройств, начиная от простых контроллеров реального времени и заканчивая POS-системами, такими как киоск самообслуживания или кассовый аппарат и промышленными системами. Windows Embedded доступна через специализированных дистрибьюторов Microsoft и должна поставляться конечному потребителю только вместе с устройством. Отличается более выгодной ценой по сравнению с настольными версиями, возможностями блокировки образа (Lockdown), продленным сроком доступности и продажи (до 15-ти лет).

Добавлю, что Windows Embedded еще и потребляет ресурсов меньше, чем обычная Windows 7, поэтому для слабых ноутбуков это то, что доктор прописал.

Неудивительно, что домашний пользователь никогда не слышал про нее. К счастью — отличия Windows Embedded Standard 7 от Windows 7 Professional небольшие, а трудности установки, русификации и обновления я сейчас вам подробно объясню.

Я не буду скачивать образ Windows Embedded Standard 7 с торрент трекера, так как это пиратство и в сборках от дяди Васи может быть что угодно: и троян, и майнер, которые не будут видеть антивирусы.

Поэтому идем на сайт Microsoft по ссылке и нажимаем «Download».

реклама

Сайт предложит несколько частей архива, выбирайте нужную вам разрядность галочками и скачивайте.

После скачивания, в папке загрузки будут лежать несколько частей архива.

Щелкайте по первой части архива и он распакуется в iso файл.

реклама

Теперь надо воспользоваться программами UltraISO или Rufus и записать образ на флешку.

Вот содержимое образа.

Но не торопитесь извлекать флешку! Надо сразу добавить и файл русификации.
Его тоже скачиваем с сайта Microsoft по ссылке.

Жмите «Download», в открывшемся списке выбирайте нужный язык галочкой.

Все готово к установке.

Меню установки отличается от такового у Windows 7 Professional, но каждый, кто хоть раз устанавливал Windows 7 — легко разберется.

Тут выбираем первый пункт.

Выбираем язык.

Далее идет установка. На мой старый ноутбук с медленным HDD устанавливалась довольно долго.

Стартовое окно отличается от обычной Windows 7.

Смотрим, что получилось.

Вот окно свойств системы и диспетчер задач. Памяти ест совсем немного. Пробный период равен 30 дням. Его можно законно продлить до 120 или 180 дней.

Теперь перейдем к русификации. Открываем панель управления.

Выбираем место хранения файла с языком.

Теперь надо включить файл подкачки, он по умолчанию отключен. Как и гибернация. Не придется вводить знакомые до боли powercfg -h off

Далее я опробовал обновление с помощью UpdatePack7R2 от simplix. Все прекрасно обновляется.

Но на таком медленном железе процесс длится очень долго, несколько часов, гораздо быстрее интегрировать UpdatePack7R2 в образ Windows.

После вышеописанных манипуляций мы имеем практически обычный Windows 7, но более шустрый и занимающий меньше места на жестком диске. И о поддержке обновлениями можно не беспокоиться еще больше года.

Я оставлю его у себя на ноутбуке и рекомендую вам попробовать.

Embedded Linux vs Windows Embedded Standard 7 [closed]

Want to improve this question? Update the question so it’s on-topic for Software Engineering Stack Exchange.

Closed 4 years ago .

Ok looking for some really subjective answers. My company has traditionally been a Linux shop, we manufacture and sell purpose built boxes for video security. We recently decided to build an Embedded Windows Standard 7 box because it shortened our development and time to market, and because of all the tools are available off the shelf for windows.

What I am looking for are some solid answers as it relates to the security of WES7 vs. Linux? How stable is WES7, how prone is it to hack attempts, virus attacks etc. From a marketing point of view what could or should one say are the benefits of using WES7 over Linux? Are there any?

What comparisons are there between the security of desktop Windows 7 and Embedded Windows Standard 7?

Any responses would be greatly appreciated. Thanks

2 Answers 2

You will need to do a few things, here are some off the top of my head (having been around this a few years ago):

You need lots of memory to run Windows Embedded 7. Check the data — you might be surprised at how much RAM you need.

Make sure you understand how the write filter works, if you are using CF or similar as your «hard drive». If you have a real spinning HD then its not such a big deal.

Do a course on using the tools. ESSENTIAL. I spent a couple of months on the previous generation tools and it was a pretty terrible time learning them. A 1 day course teaches what you will take 1-2 weeks to learn yourself. MS even offer some of these courses for free.

Figure out how you want to lock down the platform. To do this you need to do things like disable web browsers, javascript, turn off file sharing and workstation services (about 70% of all the windows services CAN be disabled and probably should be — this will depend on your application though)

Some aspects can only be locked down using manual steps on a master «golden» platform where you build the image, as manual steps hand entered, after the image build. WRITE DOWN A PROCEDURE to allow this to be replicated.

Do everything (all your target building) in a VM, and check the VM into source control after. It will be between 8 and 10 GB — make sure that your VM splits the virtual disk into 2 GB chunks to make your source control systems life easier. This sounds over the top but it will save your life 2 years later.

Check out and understand how the patch / update system works. We had to write our own, the standard one was not good enough. Things have moved on since but you still must understand this.

Line up a consultant who has done this MANY times before, and get them in for a day or a week if you need to. Make them document everything they do, and WHY. You may need help, and a few days of an experienced consultant will save you a month. A classic turning of $ into time. MAKE sure they are experienced. There are lot of BS people selling Windows Embedded out there — doing the easy 90% is (surprise) easy. The other 10% is damn hard.

Understand the requirements for branding — removing the MS logos and names and putting your own in. Its relatively easy but you must do it. You may need a graphic designer to make splash / start screens.

Go through the license agreement 10 times. It is a LOT of fine print. Your legal department will need to look at it. You MUST understand it and the implications it imposes on your AND YOUR SUPPLY CHAIN. The agreement IS onerous.

It is probably not a good idea to have windows updates enabled. You don’t want your product doing various automatic unknown updates. (which leads to:)

Make sure you know how to use and setup the windows firewall so that all ports are blocked except those used only by your application. This reduces the hack-attack surface.

If you get through all this, by all means use it. It is a very powerful platform.

Windows CE vs Embedded Linux [closed]

Want to improve this question? Update the question so it focuses on one problem only by editing this post.

Closed 5 years ago .

Now I’m sure we’re all well aware of the relative merits of Linux vs Windows Desktop. However I’ve heard much less about the world of embedded development. I’m mainly interested in solutions for industry and am therefore uninterested about the IPhone or Android and more interested in these two OSes.

What are the relative trade-offs between the two platforms in the embedded world? If you were considering building a box for a specific project with custom hardware, a partially customised OS and a custom app then which would you choose and why?

I would assume that Windows CE wins on tools and Linux wins on both cost and possibly performance. However this is just utter speculation. Does anyone have any facts or experience of the two?

8 Answers 8

I worked for several years at a company that provided both CE and Linux for all of their hardware, so I’m fairly familiar with both sides of this equation.

• Tools: Windows CE tools certainly are better than those provided by Linux, though the linux tools are certainly getting better.
• Performance: Windows CE is real-time. Linux is not. The linux kernel is not designed for determinism at all. There are extensions that you can add to get sort-of real time, but CE beats it.
• Cost: This is an area of great misunderstanding. My general experience is that CE is lower cost out of the box ($1k for Platform Builder and as low as $3 per device for a shipping runtime. «What?» you ask? «Linux is free.» Well, not really so much, especially in the embedded arena. Yes, there are free distributions like Debian. But there are plenty of pieces that you might need that aren’t in that free category. UI frameworks like QT, Java runtimes and media codecs just as a start. Also, most Linux distributions with a commercially-backed support system (e.g. MontaVista) are far from free.
• Source Availability: Linux proponents may like to say that CE is a bad choice due to lack of source code. All I can say is that in over a decade of working with CE, half of which spent doing custom kernel and driver work for custom boards, I’ve only ever had need for source that didn’t ship with CE (they ship a vast majority of it) once. I like having source too, but Microsoft provides support, so in the rare case you might think you need that source, you can get them to fix the problem (the one time we needed source, Microsoft provided a fix, and for free — which is their model under CE.

Does this mean that CE wins every time? No. I wouldn’t suggest that at all. If you are a Linux shop and you have lots of Linux experience and code assets, you’d be foolish to run out and go CE. However, if you’re coming into it from scratch CE usually has a lower TCO. Developers with Win32/C# experience are more prevalent and consequently less expensive. You also get a lot more «in the box» with CE than most other distributions, meaning faster time to market if you don’t already have these things done in-house already.

I’ll speak for the Linux side, at least for the category of software I’m familiar with (which is RF data collection equipment). Or industrial apps vs. consumer apps.

Windows CE (and its associated tools) IMH fairly recent E) is strongly biased to creating a «Windows Experience» on a small screen. The user input mode emphasizes mouse-like actions. Logons, application selection, etc. all try to be as similar to standard Windows as possible.

If a user is driving a lift truck, or filling a picking cart, or moving material from one place to another, there’s a problem.

And it’s a moving target — particularly on the .NET side. The Compact .NET runtime is seriously handicapped, and important libraries (like networking, data handling, and UI) are incomplete and versions too often deprecate the previous version. . CE seems to be the stepchild in the Windows family (possibly because there’s not a lot of active competition selling to the hardware integrators.)

A nice stable rows-and-columns Linux console is a pretty handy context for many (in my experience most) high-use apps on a dinky screen.

Not much good for games on your cell-phone or Zune, though.

I think ctacke probably speaks accurately for the hardware integrator’s side. I’m more aligned with the players further down the pipe — software integrators and users.

Choice is often made largely on perception and culture, rather than concrete data. And, making a choice based on concrete data is difficult when you consider the complexity of a modern OS, all the issues associated with porting it to custom hardware, and unknown future requirements. Even from an application perspective, things change over the life of a project. Requirements come and go. You find yourself doing things you never thought you would, especially if they are possible. The ubiquitous USB and network ports open a lot of possibilities — for example adding Cell modem support or printer support. Flash based storage makes in-field software updates the standard mode of operation. And in the end, each solution has its strengths and weaknesses — there is no magic bullet that is the best in all cases.

When considering Embedded Linux development, I often use the iceberg analogy; what you see going into a project is the part above the water. These are the pieces your application interacts with, drivers you need to customize, the part you understand. The other 90% is under water, and herein lies a great deal of variability. Quality issues with drivers or not being able to find a driver for something you may want to support in the future can easily swamp known parts of the project. There are very few people who have a lot of experience with both WinCE and Linux solutions, hence the tendency to go with what is comfortable (or what managers are comfortable with), or what we have experience with. Below are thoughts on a number of aspects to consider:

SYSTEM SOFTWARE DEVELOPMENT

Questions in this realm include CPU support, driver quality, in field software updates, filesystem support, driver availability, etc. One of the changes that has happened in the past two years, is CPU vendors are now porting Linux to their new chips as the first OS. Before, the OS porting was typically done by Linux software companies such as MontaVista, or community efforts. As a result, the Linux kernel now supports most mainstream embedded cpus with few additional patches. This is radically different than the situation 5 years ago. Because many people are using the same source code, issues get fixed, and often are contributed back to the mainstream source. With WinCE, the BSP/driver support tends to be more of a reference implementation, and then OEM/users take it, fix any issues, and that is where the fixes tend to stay.

From a system perspective, it is very important to consider flexibility for future needs. Just because it is not a requirement now does not mean it will not be a requirement in the future. Obtaining driver support for a peripheral may be nearly impossible, or be too large an effort to make it practical.

Most people give very little thought to the build system, or never look much beyond the thought that «if there is a nice gui wrapped around the tool, it must be easy». OpenEmbedded is very popular way to build embedded Linux products, and has recently been endorsed as the technology base of MontaVista’s Linux 6 product, and is generally considered «hard to use» by new users. While WinCE build tools look simpler on the surface (the 10% above water), you still have the problem of what happens when I need to customize something, implement complex features such as software updates, etc. To build a production system with production grade features, you still need someone on your team who understands the OS and can work at the detail level of both the operating system, and the build system. With either WinCE or Embedded Linux, this generally means companies either need to have experienced developers in house, or hire experts to do portions of the system software development. System software development is not the same as application development, and is generally not something you want to take on with no experience unless you have a lot of time. It is quite common for companies to hire expert help for the first couple projects, and then do follow-on projects in-house. Another feature to consider is parallel build support. With quad core workstations becoming the standard, is it a big deal that a full build can be done in 1.2 hours versus 8? How flexible is the build system at pulling and building source code from various sources such as diverse revision control systems, etc.

Embedded processors are becoming increasingly complex. It is no longer good enough to just have the cpu running. If you consider the OMAP3 cpu family from TI, then you have to ask the following questions: are there libraries available for the 3D acceleration engine, and can I even get them without being committing to millions of units per year? Is there support for the DSP bridge? What is the cost of all this? On a recent project I was involved in, a basic WinCE BSP for the Atmel AT91SAM9260 cost $7000. In terms of developer time, this is not much, but you have to also consider the on-going costs of maintenance, upgrading to new versions of the operating system, etc.

APPLICATION DEVELOPMENT

Both Embedded Linux and WinCE support a range of application libraries and programming languages. C and C++ are well supported. Most business type applications are moving to C# in the WinCE world. Linux has Mono, which provides extensive support for .NET technologies and runs very well in embedded Linux systems. There are numerous Java development environments available for Embedded Linux. One area where you do run into differences is graphics libraries. Generally the Microsoft graphical APIs are not well supported on Linux, so if you have a large application team that are die-hard windows GUI programmers, then perhaps WinCE makes sense. However, there are many options for GUI toolkits that run on both Windows PCs and Embedded Linux devices. Some examples include GTK+, Qt, wxWidgets, etc. The Gimp is an example of a GTK+ application that runs on windows, plus there are many others. The are C# bindings to GTK+ and Qt. Another feature that seems to be coming on strong in the WinCE space is the Windows Communication Foundation (WCF). But again, there are projects to bring WCF to Mono, depending what portions you need. Embedded Linux support for scripting languages like Python is very good, and Python runs very well on 200MHz ARM processors.

There is often the perception that WinCE is realtime, and Linux is not. Linux realtime support is decent in the stock kernels with the PREEMPT option, and real-time support is excellent with the addition of a relatively small real-time patch. You can easily attain sub millisecond timing with Linux. This is something that has changed in the past couple years with the merging of real-time functionality into the stock kernel.

DEVELOPMENT FLOW

In a productive environment, most advanced embedded applications are developed and debugged on a PC, not the target hardware. Even in setups where remote debugging on a target system works well, debugging an application on workstation works better. So the fact that one solution has nice on-target debugging, where the other does not is not really relevant. For data centric systems, it is common to have simulation modes where the application can be tested without connection to real I/O. With both Linux and WinCE applications, application programing for an embedded device is similar to programming for a PC. Embedded Linux takes this a step further. Because embedded Linux technology is the same as desktop, and server Linux technology, almost everything developed for desktop/server (including system software) is available for embedded for free. This means very complete driver support (see USB cell modem and printer examples above), robust file system support, memory management, etc. The breadth of options for Linux is astounding, but some may consider this a negative point, and would prefer a more integrated solution like Windows CE where everything comes from one place. There is a loss of flexibility, but in some cases, the tradeoff might be worth it. For an example of the number of packages that can be build for Embedded Linux systems using Openembedded, see.

GUI TRENDS

It is important to consider trends for embedded devices with small displays being driven by Cell Phones (iPhone, Palm Pre, etc). Standard GUI widgets that are common in desktop systems (dialog boxes, check boxes, pull down lists, etc) do not cut it for modern embedded systems. So, it will be important to consider support for 3D effects, and widget libraries designed to be used by touch screen devices. The Clutter library is an example of this type of support.

REMOTE SUPPORT

Going back to the issue of debugging tools, most people stop at the scenario where the device is setting next to a workstation in the lab. But what about when you need to troubleshoot a device that is being beta-tested half-way around the world? That is where a command-line debugger like Gdb is an advantage, and not a disadvantage. And how do you connect to the device if you don’t have support for cell modems in New Zealand, or an efficient connection mechanism like ssh for shell access and transferring files?

SUMMARY

Selecting any advanced technology is not a simple task, and is fairly difficult to do even with experience. So it is important to be asking the right questions, and looking at the decision from many angles. Hopefully this article can help in that.