imagecopy($dest_image, $a, 75, 0, 0, 0, $width, $height);
imagecopy($dest_image, $b, 0, 0, 0, 0, 150, $height);
Просто проблема с позицией - исправлено:)
Поскольку Mono не реализует .Net на 100% так же, как MS .Net Framework, хорошо, что вы можете проверить Mono без необходимости запуска на Linux. Также у Mono есть привязки для создания форм с GTK, которые MS не поддерживает.
Например, mono поддерживает статическое связывание, поэтому вы можете создавать, компилировать и распространять ваше приложение, не требуя отдельного установщика во время выполнения. Если вы создали приложение, которое полагается на моно, чтобы быть кроссплатформенным, есть некоторые отличия от .Net, и поэтому придерживаться моно в Windows - это лучшая гарантия совместимости.
В BCL есть несколько мест, которые еще не перенесены для моно, например, WPF и Winforms.
Если вам нужно приложение, которое будет также работать на Mac / Linux, вы, вероятно, захотите сначала разработать его для моно, даже если вы выполняете большую часть работы с Windows.
Примечание: все это предшествующие .Net Core / Standard.
Если вы хотите разработать кроссплатформенное приложение на C #, то использование реализации Microsoft - не самая умная вещь, так как не существует полностью совместимой альтернативы для других платформ.
Таким образом, использование Mono в Windows для разработки приложений гарантирует, что у вас не будет проблем с переносом его на другие ОС (при условии, что вы избежите других ошибок, таких как P / Invoke).
Некоторые люди использовали его, потому что им не разрешено устанавливать .Net framework на своих ПК с Windows, из-за того, что он делает много ошибок в реестре и системных файлах. (В жестко контролируемых средах.)
Mono, с другой стороны, самодостаточен в Program Files и записывает только раздел реестра с указанным в нем путем (который необязательно запускать).
Я думаю, это довольно глупо, но об этом нам говорили несколько пользователей.
Он в основном используется для помощи в разработке приложений Mono для конкретных библиотек Mono. Также для содействия продвижению дела, чтобы разработчики могли работать в своей естественной среде при разработке для Mono.
While not of widespread interest, there are a few cases where mono has improvements over the standard Microsoft runtime. Migel gave a talk on some of these at PDC this year:
See these posts:
Есть несколько функций, которые есть у Mono, которых нет в .NET.
Mono очень модульный. Вы можете разбить его на мелкие кусочки и развернуть точно те части, которые вам нужны. Не хотите System.Xml? Хорошо, это ушло.
Моно встраиваемо. Вы можете разместить его в своем приложении C / C ++, чтобы позволить пользователям создавать сценарии из безопасной управляемой изолированной среды. Наиболее известным примером этого является mod_mono, который размещает Mono внутри веб-сервера Apache и, например, как ASP.NET реализован в Mono. Эта функция прекрасно сочетается с упомянутой выше модульностью.
Это уже упоминалось: статическое связывание. Также отлично сочетается с модульностью.
Компилятор как сервис - еще один. Андерс Хейлсберг говорил об этом в течение долгого времени, и , может быть, , просто возможно, он будет готов к C # 5.0. Ну, у Моно уже есть, и на самом деле он был в течение многих лет.
Мигель де Иказа, ведущий разработчик Моно, также имеет инициативу, которую он называет «Embrace and Extend.NET», которая расширяет CLI способами, которые (в настоящее время) невозможны. с другими реализациями CLI (включая .NET). Пока что Embrace и Extend.NET имеют три функции:
Mono.Simd, который обеспечивает безопасный и контролируемый доступ к инструкциям SIMD базового ЦП (например, SSE для Intel или AltiVec для PowerPC). Используется для игр и графики.
Индексы 64-битного массива, которые разрешены спецификацией ECMA, но Mono - единственная виртуальная машина, которая фактически предоставляет их. Используется в суперкомпьютерах.
И совсем недавно, продолжения. Это фактически первый раз, когда Mono выходит за пределы области спецификации: индексы длинных массивов полностью соответствуют спецификации, а Mono.Simd также работает с каждой реализацией, совместимой с CLI (хотя очень SLOW), но Mono.Tasklet нуждается в специальной поддержке со стороны виртуальной машины, которая не является частью CLI или .NET. Это используется для игровой логики и, например, в Second Life.
Я думаю, что основная причина, по которой они это сделали, заключается в том, что они могут запускать приложения .NET в Mono и .NET параллельно. сторона, чтобы сравнить их. Также есть несколько приложений, которые зависят от библиотек Mono.
Из технических часто задаваемых вопросов Mono :
Зачем нужна поддержка Windows, если вы можете запускать настоящую вещь?
Существуют различные причины:
Поддержка Windows помогает нам идентифицировать переносимые части Mono из непереносимых версий, помогая Mono стать более портативным в будущем.
Это помогает нам, поскольку мы можем изолировать проблемы в Mono, разбив проблему на разделы (это проблема времени выполнения или проблема ОС?).
Около половины участников Mono - разработчики Windows. У них есть много разных причин для участия в этих усилиях, и мы считаем очень важным позволить этим разработчикам запускать среду выполнения в Windows {{1} }, не заставляя их использовать новую операционную систему.
Mono не сильно модифицирует реестр Windows, обновляет системные библиотеки DLL, устанавливает библиотеки DLL в путь Windows / System32 .
Это помогает разработчикам на базе Windows протестировать свой код в Mono перед развертыванием в Linux.
Mono и приложения, которые встраивают Mono, могут быть развернуты без установщика (вы можете "xcopy" развернуть приложение и необходимые файлы Mono без установки .NET { {1}} время выполнения).